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INTRODUCTION 


This  report  is  the  fifth  in  a  series  that  is  being  published  by  the 
KAPSE  Interface  Team  (KIT) .  The  first  was  published  as  a  Naval  Ocean  Systems 
Center  (NOSC)  Report,  TD-209,  dated  April  1962,  and  is  new  available  throu^i 
the  National  Technical  Information  Service  (OTIS)  for  $19.50  hardcopy  or 
$4.00  microfiche;  ask  for  order  nuntoer  AD  A115  590.  All  subsequent  issues  of 
the  public  reports  are  being  issued  as  volunas  of  NOSC  1^552.  ’Hie  second 
public  report  is  dated  October  1962  and  is  now  availabe  throu#i  OTIS  for 
$44.50  hardcopy;  ask  for  order  nuntoer  AD  A123  136.  The  third  is  dated  October 
1963  and  is  available  through  OTIS;  ask  for  order  nuntoer  AD  A141  576.  The 
fourth  is  dated  30  April  1964  and  will  be  available  through  OTIS.  This  series 
of  reports  serves  to  record  the  activities  vhich  have  taken  place  to  date  and 
to  submit  far  public  review  the  products  that  have  resulted.  The  reports  are 
issued  approximately  every  six  months.  They  should  be  viewed  as  snapshots  of 
the  progress  of  the  KIT  and  its  oenpanion  team,  the  KAPSE  Interface  Team  frtan 
Industry  and  Academia  (KIT1A) ;  everything  that  is  ready  for  public  review  at 
a  given  time  is  included.  These  reports  represent  evolving  ideas,  so  the 
contents  should  not  be  taken  as  fixed  or  final . 

MEETINGS 


During  this  reporting  period  the  two  teams  met  jointly  in  July  1964  in 
Toronto,  Canada,  and  in  October  1964  in  Merrimack,  New  Hanpshire.  The 
approved  minutes  from  the  April,  July  and  October  1964  meetings  are  included 
in  this  report.  As  usual,  some  of  the  waricing  groups  have  also  held 
individual  meetings  between  regular  KTr/KITIA  meetings. 

COMMON  APSE  INTERFACE  SET  (CAIS) 


Since  one  of  the  frequently-heard  cements  on  the  CAIS  was  that  there 
was  insufficient  public  involvement  in  its  review,  it  was  decided  to  hold  two 
more  public  reviews  before  the  scheduled  delivery  of  a  CAIS  Version  1 
document  to  the  AJPO.  Version  1.3  of  the  CAIS  vms  drafted  by  the  CAI943  and 
distributed  in  August  in  conjunction  with  a  second  Public  Review  meeting  on 
2  August  1984  in  Hyannis,  Massachusetts,  that  was  held  immediately  following 
the  AdaTBC  meeting  there.  About  100  people  participated  and  provided  the 
CAISWG  with  many  useful  ccnments.  A  sunnary  of  this  meeting  and  the  cements 
made  is  included  in  this  report. 

The  following  day  the  key  CAIS  designers  met  with  Dr.  Robert  Mathis, 
director  of  the  AJPO.  It  was  decided  that,  based  on  the  results  of  the  review 
the  previous  day,  the  work  would  proceed  an  schedule  with  a  January  1965 
delivery  to  the  AJPO  of  a  docunent  which  vculd  be  put  forward  for 
standardization  by  the  three  services.  It  was  also  decided  to  hold  an 
additional  public  review  meeting  in  Noventoer  in  conjunction  with  the 
AdaJUG/SIGAda  meeting  scheduled  for  Washington,  D.C.  In  response  to  this,  the 
CAISWG  held  a  special  meeting  in  October  1984  to  produce  an  additional 
revision,  CAIS  1.4,  of  the  interface  set.  That  version  is  included  in  this 
report. 

It  was  also  decided  in  this  time  period  that  the  CAIS  Version  2  which  is 
due  for  delivery  to  the  AJPO  in  January  1967  should  be  developed  by  a 
contractor  and  that  the  contractor  would  be  selected  ccrpetitively,  although 
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it  was  determined  that  parallel  competitive  contracts  such  as  were  used  to 
develop  Ada  would  not  be  pursued.  A  Request  for  Procurement  was  prepared  by 
NDSC  and  announced  in  the  Commerce  Business  Daily  in  September.  Award  of  that 
contract  is  expected  in  1985. 


REQUIREMENTS  AND  DESIGN  CRITERIA  (RAC) 

Wbrk  an  the  RAC  has  now  produced  a  version  which  has  been  accepted  by 
the  KXT  and  KOTA  for  baselining?  it  now  includes  all  sections  anticipated 
for  the  docunent.  That  means  that  the  groups  have  agreed  to  the  contents  in 
concept.  The  October  version  of  the  complete  RAC  docment  is  included  in  this 
report.  It  includes  sli^it  revisions  of  some  previously  baselined  sections,  a 
significant  re-write  (more  in  terms  of  style  than  content)  of  the  previously 
baselined  section  on  processes  and  newly  baselined  versions  of  the  sections 
on  the  database  and  on  the  input  and  output. 

This  docunent  is  considered  to  be  quite  important  to  the  future  work  of 
the  KIT  and  KOTA  as  it  encompasses  the  requiranents  to  which  Version  2  of 
the  CMS  is  to  be  designed.  It  is  important  that  this  receive  considerable 
public  review  before  work  on  Version  2  proceeds  too  far.  All  comments  on  that 
part  of  this  report  are  especially  welcome. 

STANDARDS  CSTANDWG) 

Because  of  the  email  number  of  members  involved  in  the  Standards  Working 
Group  (SEANDWG),  it  was  decided  to  incorporate  its  charter  with  that  of  the 
Compliance  Working  Group  (GGMEVJG).  Reviews  of  standards  that  nay  be  of 
interest,  such  as  the  one  included  in  this  report,  will  continue  to  be 
produced,  however. 

POLICY  DISCUSSIONS 

Policy  issues  have  continued  to  be  a  subject  of  extreme  concern  to  the 
members  of  the  KIT  and  KOTA.  These  concerns  evoked  serious  discussions  at 
the  July  meeting  regarding  CAIS  standardlzwti on  and  hour  the  DcD  should 
proceed  regarding  derivation  of  CAIS  Version  2.  These  discussions  culminated 
in  an  invitation  to  Dr.  Mathis  and  the  three  military  service  program 
managers  to  join  the  teems  for  a  discuon  at  the  October  meeting.  Same  of 
these  concerns  and  KOTA  reoonmandatiens  with  regard  to  them  are  reflected  in 
the  KOTA  proposal  for  a  second  CAIS  Version  2  contract,  which  is  included  in 
this  report. 


I&T  TOOLS 

The  work  to  implement  the  APSE  Interactive  Monitor  (AIM)  has  continued 
with  the  acquisition  of  a  Data  General  (DG)  system  running  the  Ada 
Development  Environment  (ACE).  The  completion  of  this  work  will  result  in  an 
AIM  implementation  on  the  DG  and  is  expected  in  June  1985. 


KIT/KITIA  PAPERS 


Only  one  paper  is  included  in  this  report  vhich  vms  generated  toy  an 
individual  ranter  of  the  KIT  or  KZTIA.  This  paper,  toy  Or.  Chris  Napjus  of  the 
KIT,  articulates  some  of  the  ideas  which  have  been  discussed  oonceming  the 
concept  of  a  standard  MAPSE  (i.e. ,  one  minimal  set  of  tools  which  are  ALWAYS 
available  identically  on  ALL  APSEs). 


OTHER  KIT/KITIA  ACTIVITIES 

The  planning  activities  for  the  Ada  Rm-Time  Environment  Working  Group 
(AKTBNG)  have  continued  and  the  attendance  has  been  increasing.  There  is 
growing  interest  in  the  oonmunity  in  issues  which  this  group  is  addressing. 

The  CAIS  Implementor '  s  Group  (CXG)  held  its  first  meeting  in  June  in  San 
Diego.  Rebecca  Bowennan  (MITRE)  was  elected  chairperson,  and  the  group  made 
various  decisions  regarding  how  it  would  consider  the  addition  of  members  and 
what  its  goals  and  mode  of  business  would  toe.  A  subsequent  meeting  was  held 
in  Hyannis  in  conjunction  with  the  AdaTSC  meeting  there  in  August  and  another 
meeting  was  planned  for  the  Novenber  AdaTBC  meeting  in  Washington,  D.C. 

CONCLUSION 

This  Public  Report  is  provided  toy  the  KIT  and  KOTA  to  solicit  ocnments 
and  feedback  from  thoee  who  do  not  regularly  participate  on  either  of  the 
teams.  Consents  on  this  and  all  previous  reports  are  encouraged.  They  should 
be  addressed  tot 

Patricia  Otoemdarf 

Code  423 

Naval  Ocean  Systems  Center 

San  Diego,  CA  92152-5000 


or  sent  via  ARPANET/MIMET  to  FOBERNDORF@EELB 
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KIT/KmA  MINUTES 
9-12  APRIL  1964 
SEATIUi,  WA 


ATTENDEES*  SEE  APPENDIX  A 
HANDOUTS*  SEE  APPENDIX  B 
WORKING  GROUP  MEMBERS:  SEE  APPENDIX  C 
PLANNING  GROUP  NECERS:  SEE  APPENJIX  D 

9  APRIL  1964  -  KTITA  NEE7TING 

1.  OPENING  REMARKS 

•  Hem  Fischer,  KITIA  chairperson,  trou^it  the  meeting  to  order.  All 
were  welcomed. 

2.  GENERAL  BUSINESS 

•  Hem  Fischer  gave  a  presentation  of  an  Onion  Skin  Model  to  add  to 
discussion  of  a  layering  to  the  KITIA.  A  OODSIA  Report  was  made 
available  to  explain  the  model. 

•  Discussion  of  the  layered  KITIA  took  place,  and  it  was  decided  that 
the  two  of  Judy  Kemer  and  Eli  Lant)  would  be  formalized  and 
presented  later  in  the  meeting. 

•  The  question  of  a  Run  Time  working  group  made  up  of  an  independent 
team  was  brought  up.  This  team's  objective  would  be  to  look  into 
the  issues  of  Run  Time  standards,  not  necessarily  taking  as  a  premise 
that  we  have  a  Run  Time  Standard. 

e  Tricia  announced  to  the  guests  the  named  and  rnmber  working  groups 
and  encouraged  the  guests  to  join  Whichever  group  they  seemed  most 
interested  in. 


3.  KITIA  MEETING  ADJOURNED 


10  APRIL  1964  -  JOINT  KIT/KITTA  MEETING 


1.  OPENING  REMARKS 

e  Tricia  Obemdorf,  KIT  chairperson,  brought  the  meeting  to  order. 

•  New  replacement  members  and  visitors  were  introduced.  Bill  Barry  of 
PCDSSA,  San  Diego  is  here  to  replace  George  Robertson.  Tan  Conrad 
from  NUSC  is  Ron  House's  replacement.  Cheng-Chi  Huang  of  Hughes 
is  here  instead  of  Jim  Ruby.  Geoff  Fitch  from  Interne  tries  is  here 
instead  of  Jim  Moloney.  Na*  members  are  Tony  Steadknan  of  ESD,  his 
alternate  Bob  Munck  from  MITRE  and  Susan  Good  from  NO. XI  with  Tricia. 
Visitors/Guesta  are  Ben  Brosgol  of  Alsys,  Mike  Dolbec  of  Rational, 
Larry  Druffel  of  Rationed,  Gerry  Fisher  of  CSC,  Sylvester  Fernandez 
of  Sperry,  Dean  Herington  of  Data  General  and  Charles  McKay  of  NASA/ 
University  of  Houston  at  Clear  Lake. 


2.  GENERAL  BUSINESS 
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•  Status  of  the  TI,  TW  contracts  and  E&V  task  were  presented.  Hem 
tock  the  floor  to  suimarize  the  KTFIA  meeting  of  Monday,  9  April 
1984.  A  discussion  of  the  Onion  Model  and  a  layered  KIT/KITIA  were 
presented.  Anthony  Gargaro  was  also  appointed  tenporary  chair  of  the 
Rui  Time  Planning  Groqp. 

3.  NAMED  WORKING  GROUP  REPORTS 

•  Jack  Kramer  of  the  CAISWG  discussed  that  GAIS  version  1.2  would  be 
delayed.  Accomplishments  are  work  done  on  mandatary  and 
discretionary  security  and  distribution/work  stations.  Projected 
work  includes  changes  due  to  ocnments.  GAIS  Version  1.2  will  be 
due  next  quarter  and  will  include  changes  from  1.1  to  present.  At 
next  meeting  plans  are  to  discuss  remaining  items  for  1.3.  A  CAISWG 
fbmn/warkshop  is  being  planned  for  2  August  at  the  Hyannis  AdaTEC. 

e  Hal  Hart  of  the  RACWG  discussed  the  RAG's  approval  as  an  action  item 
for  the  meeting.  Accomplishments  are  the  rewrite  of  the  RAC (17  Feb) 
based  on  the  January  meeting,  the  development,  distribution, 
collection  and  analysis  of  the  17  responses,  and  the  revision  of  the 
document  23  March  1964.  Unresolved  problems  are  sections  4  and  6 
Projected  vnrk  is  the  approval  of  section  4  and  6,  to  begin  the 
rationale  far  the  RAC,  and  begin  evaluation  of  the  CAIS  against 
the  RAC.  Item  due  next  quarter  is  a  complete  approved  RAG  docunent. 
Presentation  planned  far  next  meeting  is  status  of  the  docunent. 
Discussion  of  procedures  far  approving/ disapproving  the  RAG  then 
took  place.  Tricia  also  expressed  her  disappointment  in  only  17 
responses  to  the  earlier  draft. 

e  Ann  Reedy  of  SPONEWG  discussed  items  due  this  quarter.  She  reported 
that  a  decision  was  made  to  make  a  preliminary  analysis  of  the  STCNEMAN 
docunent.  There  is  currently  a  draft  of  these  analyses.  The 
unresolved  problem  is  primarily  a  long  term  work  schedule. 

Projected  work  includes  a  cross  reference  for  the  RAG  and  a 
presentation  by  Frank  Belz  of  TFW's  PA-APSE  work  at  the  next  meeting. 
Everything  else  is  TBD. 

e  Ron  Johnson  and  matters  of  the  GACWG  cure  currently  working  on  a  draft 
of  4  chapters  of  the  docunent.  They  have  acme  to  find  out  that  after 
looking  at  the  users  guide  to  transportability  there  is  more  than  the 
CAIS  to  nmking  a  transportable  tool  set.  The  more  they  investigate 
the  more  they  find  out  they  need  to  look  into.  The  group  is  in  hopes 
of  having  a  ocnplete  draft  of  a  Guidelines  And  Criteria  docunent  by 
Decenter,  entitled  "A  User's  Guide  to  Ada  Transportability." 

e  Rudy  Krutar  of  the  DQViG  stated  the  ocnbined  glossary  is  due  this 
quarter.  Drafts  are  available .  Acccnplishments  are  an  established 
definitions  pool,  a  draft  of  the  CAIS  glossary,  and  a  combined 
glossary  for  the  RAG  and  CAIS.  Unresolved  problems  are  moving  the 
definitions  pool  to  ECLB,  and  the  KIT/KITTA  review  of  the  combined 
glossary.  Projected  work  for  next  quarter  is  an  additon  of  the 
STCNI2MAN  tern*  to  the  glossary  and  the  open  definitions  pool  for  the 
KTT/KLTIA.  Items  due  next  quarter  are  TBD.  Presentations  planned  for 
next  meeting  are  how  to  use  the  definitions  pool.  Dission  of  a 
glossary  for  every  docunent  and  format  for  definitions  followed. 


•  Bemie  Abrams  of  the  SEANDNG  stated  that  a  draft  charter  is  due  this 
quarter.  Acccnpliahmants  this  quarter  are  review  of  the  Meta  Specs, 
DOD  4120.3  and  MIL  SID  962.  Unresolved  problems  are  CAIS  ocapl.  lance 
to  MIL  SID  962  and  personnel.  Clarification  wee  mads  as  to  the  role 
of  the  STANDING:  to  mbke  an  "offical"  docunent  and  not  to  make  sure 
everyone  a  standard  CAIS.  Work  for  next  quarter  is  to  revim* 

the  <AIS  for  compliance  and  review  existing  standards  for  conflict. 


Tim  Unquiet  of  OOMPNG  stated  that  this  groqp  is  still  in  the 
formulation  staqe.  There  are  no  real  items  dus  this  quarter. 

Activities  are  the  relationship  between  RAC  and  the  CAIS  and  the 
senmntics  of  the  CAIS.  unresolved  problems  are  taking  the  charter 
of  the  OOMPNG  and  defining  a  set  of  deliverables,  deciding  what 
standards  relate  and  configuration  management  of  the  CQMftK3  activities/ 
tracking  different  versions.  Projected  work  is  a  deliverables  list. 


ANNOUNCEMENTS 

e  CM  workshop  last  June  -  participants  are  asked  to  review  their  sections. 

e  Public  Report  IV  closes  30  April.  People  with  individual  papers  should 
give  them  to  their  working  groqp  chairs. 

e  CAIS  acmnants  and  responses  will  be  available  the  weak  of  16  April  in 
KTXVINEOEMUTON. 

e  RADC  is  another  source  for  the  Public  Report  III,  aost  is  35  dollars. 

e  A  proposal  far  the  CAIS  Inplementars  (koip  is  in  the  works.  A  meeting  is 
scheduled  for  early  Jtme.  Tricia  does  not  plan  to  head  it.  She  just 
plane  to  have  a  kick-off  meeting  in  hopes  the  groip  will  organise 
and  start  itself. 

e  A  Hunan  Factors  workshop  is  being  hosted  by  IDA  in  early  May  by 
invitation  only.  Talk  to  Jack  Kramer  for  more  information. 

e  IEEE  announced  a  conference  in  Ada  Applications  in  Bwironments  for 
mid  October.  Topics  include  education,  programming  techniques, 
design  methodologies,  environmental  structures,  and  distributed 
environments.  Papers  due  15  May. 

e  Rocky  Mountain  Institute  of  Software  Engineering  is  hosting  a 
conference  for  16-31  July.  A  oatplete  brochure  is  available 
through  Tricia. 

e  The  CAIS  made  the  Government  Gcnputer  News,  April  1964. 

e  The  KTTIA  policy  statement  mode  the  Language  Control  Facility 
Newsletter  for  the  Alia  Jovial  Working  Group. 

e  There  will  be  a  CAIS  session  at  AdaEurope,  Brussels  this  June. 

e  The  question  was  asked  if  anyone  would  be  interested  in  X3H1- 
the  groqp  working  on  the  OSCRL  docunent. 

•  An  invitation  to  join  under  the  OXSIA/OSCRL  ocnraittee  to  work 
an  model  screen  driven  operation  systems  was  announced. 


5.  MEETING  SCHEDULE 


1964 

July  16-19  Toronto 

October  1-4  New  Hampshire/  San  Francisoo 


1965 

January  San  Diego 

April  Washington  D.C. 

July  San  Francisoo 

Septenfcer  Gonnecticut/Texas/United  Kingdom  (?) 


1966 

January  San  Diego 

6.  NEW  BUSINESS 


•  Tricia  expressed  her  thanks  from  the  group  to  Ron  Johnson,  the  meeting 
host,  on  the  nice  arrangements. 

•  There  was  a  proposal  from  Tim  Lyons  for  a  birds  of  a  feather  session 
on  formal  definitions  of  the  CAIS.  A  group  was  formed  and  a  meeting 
planned. 

•  Numbered  Working  Group  Chairs  ware  informed  to  contact  Debbie  Barba 
for  forwarding  directories. 


7.  ADDRESS  FROM  BRAIN  9CHAAR 

a  Brian  ocnmended  the  grtxp  on  its  acocnplishments  and  informed 
everyone  of  his  moving  more  towards  education  and  training  and  less 
involvement  with  the  KIT/KITTA. 


8.  M3RNING  BREAK 


9.  REQUIREMENTS  AND  CRITERIA  TOIE 

e  Discussion  of  approval  of  the  docixnent  and  format  of  the  vote  took 
place.  The  vote  was  taken  in  written  ballot  to  the  following  statement 

Resolvedt  This  section  of  the  RAC  document  substantially 
represents  the  correct  set  of  requirements  for 
the  CAIS,  and  shall  be  placed  under  configuration 
management  and  in  Public  Report  IV. 

The  vote  was  taken  in  silent  ballot  for  section  2,3,5  and  7  (  4  and  6 
were  optional). 


10.  LUNCH 


11.  NAM ZD  WORKING  SOUP  MEETINGS 


14.  NUfiERH)  WORKING  (SOUP  NESTINGS 

15.  JOINT  KCT/KmA  RAC  DISCUSSION 

•  The  me  votee  were  presented,  and  the  RAC  docvmant  sections  2,3,5  and  7 
villi  be  placed  under  oenfiguratien  management  and  in  Public  Report  IV. 

The  sections  2,3,5  and  7  were  approved  with  conments.  Tricia  stated 
that  She  sees  a  conflict  in  oanplete  and  90%  IfcT.  The  RAC  right  now  reads 
for  complete  I&T.  She  also  strongly  suggests  that  WG3  put  vg>  on  the  net 
the  differences  between  operating  systems  and  interfaces. 

e  Section  7  was  presented  by  Nick  Baker,  and  it  was  decided  that  the 
entire  section  disappear  and  be  incorporated  in  other  existing 
sections. 

e  Section  5's  name  is  changed  to  Execution  Facilities.  Presentation 
and  discussion  of  the  initiation,  termination,  ocamuiication  and 
synchronization  issues  of  this  section  took  place.  Also  discussion  of 
the  vote  awhere  that  puts  the  docment  occured. 

e  Section  6  was  also  presented  and  discussed.  Changes  nnda  and  ideas  to 
add  in  the  future  to  the  document  were  discussed  in  each  part  of  this 
section. 

e  Section  4  was  presented  by  Tim  Lyons  with  discussion.  Decisions  made 
by  the  groqp  are  on  the  following  topless  basic  levels  of  dynamic  database 
abstraction  mechanisms,  affirmation  of  abject/attribute/ relationship 
approach,  uni-and-bi-directicnal  relationships,  objects  never  die 
(they  just  become  inaccessible  and  relationships  to  these  objects 
become  unaffected),  detailing  of  relationship  type,  many-to-many 
discussion,  move  security,  processes  in  5  should  have  relations  to  4, 
and  other  dbms's  (as  a  measure  of  capability  not  as  a  requirement  it 
be  used  as  such.)  Issues  to  address  are  object/ relationship/ attribute 
identity/ select/ operations ,  detailing  of  object,  relationship  and 
attribute  operations,  transactions  and  dynamic  access  synchronization, 
and  integrity,  back-up,  archiving,  and  history. 


THURSDAY,  12  APRIL  1964 


16.  HEX  AND  THE  CMS:  ISSUES  AND  DISCUSSION 

e  Eli  Lanb  first  presented  a  Unix  tutorial  then  went  on  to  describe  the 
motivation  for  a  Unix-based  approach  (timely,  credible,  and  economical). 
Rich  Thall  then  spoke  of  the  problems  with  using  Unix  as  a  base.  He 
brought  wp  the  issues  as  technical  vs.  administrative.  Issues  include 
vhat  definition  is  to  be  used  and  vho  supports  the  product. 


•  Eli  wsnt  on  to  clarify  the  Unix  System  I/O  and  tasking  and  to  describe 
the  problem  of  Unix's  System  Support  for  tasking. 


•  In  sixmmry  the  CMS  approach  based  on  existing  systeros  is  attractive. 
Concerns  are  control  and  technical.  The  technical  concerns  are 
surmountable.  The  ALS  and  AIE  are  both  reasonably  ocnpatible  with 
the  Unix-based  approach.  The  issues  are  a  schedule  and  the  eoonanics 
of  the  CMS. 


17.  MAMS}  WORKING  (SOUP  NESTINGS 

18.  KCT/KITIA  SEPARATE  MEETINGS 

e  At  the  KTITA  meeting  a  discussion  and  vote  took  place  as  to  the  idea  of 
a  layered  KTITA.  Two  view  points  were  presented  by  Eli  and  Judy.  The 
vote  wes  taken,  and  it  was  decided  to  have  ND  change  to  the  KTITA.  It 
is  assured  that  the  KTITA  chair  retains  the  power  to  invite  guests  on 
a  limited  basis. 

e  There  was  a  review  of  the  Onion  Model  to  clarify  the  organization  and 
role  of  the  KTITA  members.  Harm  asked  for  input  on  guests  and  will  try 
to  keep  the  mxriber  of  guest  between  4  and  6. 

19.  LUNCH 

20.  NUW3ERED  WORKING  GROUP  NESTINGS 

21.  KCT/KOTA  WRAP  UP  AND  CMS  STATUS 

•  The  CAIS  schedule  was  discussed  and  an  ipdated  version  will  be  available 
an  the  ARPANET.  Public  Report  IV  papers  are  Fitch's  papers  an  mandatory 
and  discretionary  access  controls  and  Larry  Yelowitz  ’  s  paper  an  formal 
semantics. 

e  DEFWG  stated  that  they  are  nearly  at  a  consensus  on  Definitions  for  the 
CMS  to  be  in  Public  Report  IV  and  the  RAC  docixnent. 

e  STONEWG  stated  the  draft  of  the  definition  for  the  term  APSE  for  DEFW3 
and  the  status  report  of  SPCNEWG  will  be  put  in  Public  Report  IV. 

e  GACNG  will  have  a  GAC  docunent  for  review  in  Toronto. 

e  STANDNG's  report  was  more  of  their  original  report  with  the  announcement 
of  a  new  lumber,  Tony  Steadman,  and  discussion  of  their  relation  to  the 
C0MPW8. 

e  CEMTOG  aooonplished  their  deliverables  list.  They  plan  to  have  a  draft  of 
objectives  for  the  OCtCWG  in  Toronto  and  one  for  the  KIT/KITIA  at  the 
October  JOT/KITTA  meeting. 

e  RACWG  discussed  the  appearance  of  the  RAC  in  Public  Report  IV.  A  consensus 
was  arrived  at  to  let  Tricia  and  Hal  make  public  the  RAC  docixnent  with  an 
explanation  as  to  expected  changes.  The  RAC  schedule  was  then  presented. 


22.  MEETING  ADJOURNED 


■  m  *3t  u  p-jbp 


TAFT,  Tucker  Interwetrice 

TAYLOR,  Guy  FCDSSA-EN 

THAU,,  Rich  SoffTech 

WILDER,  Bill  PMS-408 


► 


**  ^,1S^Nr*  ,?y 
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APPENDIX  B  -  NESTING  HANDOUTS 


1.  "DOD  Requirements  and  Design  Criteria  for  the  Cannon  APSE  Interface  Set", 
Draft  23  March  1964. 

2.  "Draft  Specification  of  the  Cannon  APSE  Interface  Set  (CMS)  Version  1.1.1 
9  April  1964. 

3.  "0C06IA,  Council  of  Defense  and  Space  Industry  Associations  Report  13-62, 
Volume  II,  Background  and  Issues,  DGO  Management  of  Mission-Critical 
Computer  Resources",  March  1964. 


APPENDIX  C  -  NAMB)  MORONS  GROUP  MBCCRS 


GAISHG  Matan: 

BARBA,  Dabbia 
FISCHER,  Bara 
FTP®,  Gaoff 
FRCFKXD,  Barbara 
GOOD,  Sunn 
GOUW,  Bob 
GRANT,  Branda 
HARRIS®,  Tin 
SI  liljixiR,  John 
KEAN,  Elizabeth 
KRMCR,  Jack 
LAW,  J.  Eli 
UftMS,  Tim 
MoGONAGU,  Dan 
M3RSE,  H.R. 
OBERNDORP,  Trida 

Erhard 

SCHAAR,  Brian 
TAFT,  Tuckar 
THALL,  Rich 
WELDER.  Bill 
WIZIMAN,  Barb 
YELONITZ,  Larry 


U if 

Litton  Data  Systnoa 

Intamatrics 

CBODM 

TIM 

IDA 

Taaa  Inatrmnta 

CBOOM 

RADC/OOES 

IDA 

Ball  Labs 

Software  Sdancaa  Ltd. 
<Z  OVD 

Frey  Padarel  Syatana 

mBn 

IABG 

want  Ganna ny 
AJFO 

Intamatrics 

SofTaCh 

£96-408 

Raythaon  Ooqpany 


Fond 


CEMPWG  ManterS: 


BARKY-,  Bill 
CASTOR,  Jinny 
OXC,  Fred 
DRAKE,  Dick 
FREEDMVN,  Ray 
FOUL,  Jade 
LZMDQUIST,  Tin 
PEELE,  Shirley 

DEFMG  Matters: 

BAKER,  Ride 
KEENER,  Judy 
KHJTAR,  Rudy 

GACHG  Matters* 

DUDASH,  Ed 
FRENCH,  Stewart 
JCHNSCN,  Ron 
LUELEY,  Larry 
VALTRIP,  Chuck 
MAGLIERI,  Lucas  M. 
FUDMIK.  Andy 


FCDSSA-SD 

AFVAL/AAAF 

Georgia  institute  of  Tedmology 
IBM 

Bazeltine  Carp. 

TEW 

Virginia  Institute  of  Technology 
FCDSSArCN 


McDonnell  Douglas  Astronautics 

Harden  Systata 

NRL 


NSNC/CL 

Texas  Instzuosnts 
Boeing  Aerospace  Co. 

RAC 

John  Hopkins  Univ. 
Rational  Defense  Hgds. 
GTE  Netwcrie  System  R&D 


RACWG  Mentoers 


OORtHMi,  Dennis 

Honeywell/SRC 

FELLOWS,  Jon 

Systems  Development  Corp. 

GARGARO,  Anthony 

CSC 

HART,  Hal 

TO# 

HUANG,  Cheng-chi 

Hughes  Aircraft  Go. 

KOTLER,  Reed 

Lockheed  Missiles  &  Space 

MII1£R,  Jo 

NHC 

MUNCK,  Bob 

MITRE 

M5fERS,  Philip 

NAVHLZX 

OBERNDORF,  Tricia 

NOSC 

SXBLEf,  Edgar 

Alpha  Onega  Gnxp>,  Inc. 

WESTERMAIN,  Rob 

TND-IBBC 

The  Netherlands 

WKBGE,  Doug 

Control  Data  Corp. 

STANDWG  Members: 

ABRAtC,  Bemie 

Gnsnnan  Aerospace  Corp. 

LOPER,  Warren 

NOSC 

STEADMAN,  Tony 

E5D/ALHE 

STCNEWG  Menbers: 

BEXjZ,  Frank 

TO# 

GONRAD,  Tan 

NUSC 

FERGUSON,  Jay 

DoD 

GEASEMAN,  Steve 

Aerospetoe  Corp. 

APPENDIX  D  -  PLANNING  GROUP  t©CERS 

RUNPG  Menbers: 

ABRAMS,  Bernard  Gnuraan  Aerospace  Carp. 

BAKER,  Nidc  McDonnell  Douglas  Astronautics 

BBJZ,  Frank  TRW 

BROSGCL,  Ben  Alsys 

DRAKE,  Dick  IBM 

DRUFFEL,  Larry  Rational 

FELLOWS,  Jon  System  Development  Carp. 

FERNANDEZ,  Sylvester  Sperry 

FISCHER,  Herman  Litton  Data  Systems 

FISHER,  Gerry  CSC 

FREEMAN,  Roy  Hazel  tine  Carp* 

GARGARO,  Anthony  CSC 

HART,  Hal  TM 

HERMGICN,  Dean  Data  General 

HUANG,  Cheng-chi  Hughes  Aircraft  Co. 

JCttBCN,  Ron  Boeing  Aerospaoa  Carp. 

JCaSPGN,  Larry  NADC 

WERNER,  Judy  Norden  Systems 

MILLER,  JO  NWC 

MUOWICHCW,  Isabelle  TRW 

MYERS,  Philip  MVBZX 

WILDER,  Bill  PEB-408 
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Minutes 
of  the 

KIT/KITIA  Meeting 
16-19  J«1g  1984 

Terento,  C«M4a 


ATTENDEES :  See  Appendix  A 
HANDOUTS :  See  Appendix  B 

16  July  1984 

1  Numbered  Working  Group  Meetings  0800-1200 

2.  Named  Working  Group  Meetings  1300-1700 


16  July  1984 -KITIA  MEETING 

1 .  Herm  Fischer,  KITIA  chairperson,  brought  the  meeting  to  order. 

2.  Herm  reviewed  the  status  of  the  KITIA  which  he  believed  was  about  half  complete  regarding  its 
original  charter.  The  KITIA  may  want  to  identify  new  goals  for  future  activity . 

3.  A  discussion  of  Gerry  Fisher's  comments  in  Ada  LETTERS  followed.  Although  a  time  warp  was 
evident  between  when  the  article  was  written  and  when  it  was  published,  the  KITIA  felt  the 
concerns  regarding  the  ALS  were  stilT  valid.  The  CAIS  has  made  steady  progress  but  the  focus  is 
still  in  the  paper  realm. 

4.  GENERAL  BUSINESS 

e  There  has  been  no  KITIA  objection  to  the  thirty  member  limit. 

e  The  KITIA  chair  requests  feedback  on  the  need  for  an  implementors  board. 

a  Olivier  Routine  will  be  joining  the  KITIA  as  a  representative  of  the  EEC.  Teieoyne  has  resigned 
their  seat  on  the  KITIa.  Mike  Kamrad  is  the  Honeywell  representative  ana  Cheng-Chi  Huang  is 
present  for  Hugnes  Aircraft. 

e  Anthony  Gargaro  summarized  the  background  and  status  of  the  Run-Time  Planning  Group  (RUNPG.i 
which  will  meet  the  day  after  the  KIT  /KITIA  meeting.  They  expect  to  have  a  preliminary  report 
for  the  next  SIGAda  meeting.  The  emphasis  of  this  meeting  is  to  establish  a  charter  and  goals 

•  A  CAIS  Implementor's  Group  held  their  initial  meeting  in  San  Diego.  The  group  is  composed  ot 
companies  and  organizations  that  may  implement  the  CAIS.  Rebecca  Bowerman  was  elected  as 
the  Chairperson  of  the  group  at  this  first  meeting 

5  KITIA  CAIS  Policy  and  Direction 

*  Eli  Lamb  offered  some  considerations  regarding  the  CAIS  With  the  Second  Pit  lie  Review  J  -?■>* 

CAIS  scheduled  for  Hyamis  the  KITIA  may  want  to  examine  the  CAIS  from  the  perspective 
*he  A!E,  the  ALS  ,  or  some  compiler?  for  a  different  perspective  rred  Cox  expressed  concern 
that  the  DoO  will  not  listen  to  offered  criticism /opinions  and  will  go  ahead  with  MIL-STD  •  and  2 
•n  direc’  evolution  from  Versions  1.1,1  2  but  without  significant  changes  “he  k:t:a  shr-Ad 
consider  drafting  a  recommended  policy  for  consideration  by  *he  nJPO. 
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•  The  present  policy  is  vague  in  certain  areas  and  totally  lacking  in  others.  For  example,  a  CAiS 
♦hat  is  "upwards  compatible”  would  be  great  but  do  we  know  enough  now  to  define  a  reasonaole 
base  for  the  next  ten  years?  How  do  we  go  from  our  old  systems  to  Ada?  Are  subsets  allowed 
and  how  can  compliance  be  established  for  subsets?  The  lack  of  working  prototypes  is  a 
significant  issue :  we  need  operational  experience.  Additional  concerns  within  the  Ada  community 
are  the  level  to  which  the  interfaces  are  defined,  the  impact  of  the  CAIS  on  the  overall  *da 
Program  (will  it  slow  down  the  utilization  of  Ada),  how  to  get  industry  to  implement  the  CAIS, 
and  if  in  fact  a  CAIS  is  technically  and  politically  viable. 

e  Edgar  Sibley  stated  if  we  do  not  have  a  Standard  soon  we  will  have  many  problems  in  Ada  with 
interoperability. 

•  Tim  Lyons  presented  the  STOfCMAN  concept  of  building  the  environment  around  the  database. 
Without  a  database  concept  the  CAIS  is  fairly  conventional.  Since  we  understand  conventional 
systems  it  is  feasible  to  standardize  the  CAIS.  But  since  we  have  no  experience  on  environments 
built  around  a  database  we  realkj  don't  know  how  it  should  look  or  work  in  practice  and  we 
desparately  need  experimentation  in  this  area.  Standardization  normally  builds  on  existing 
implementations  of  which  we  have  none  so  the  CAIS  becomes  a  design  exercise,  not  just  a 
standardization  effort.  Since  the  DoO  Is  going  to  standardize  the  CAIS  the  KITIA  should  try  ♦? 
make  it  as  good  as  it  can  possfely  be. 

•  Tricia  Obemdorf  reviewed  the  DoD  development  schedules  of  the  AIE,  the  ALS,  and  the  ALS/N, 
the  STARS  concern  for  near-term  interfaces  and  VHSIC  commitments  to  a  full  CAIS.  The  CAIS 
development  and  standardization  effort  becomes  a  focal  point  for  these  various  programs . 

•  Eli  Lamb  presented  some  alternatives  for  consideration  including : 

-  definition  of  an  evolutionary  path  to  a  standard  CAIS 

-  wait  for  more  prototypes  for  evaluation 

-  start  over  at  a  lower  level  or  use  an  existing  base  such  as  UNIX 

-  define  subsets  for  piggy-back  implementations 

6.  Herm  Fischer  prepared  a  KITIA  ballot  for  the  following  issues.  KITIA  results  are  included. 

•  Should  the  CAIS  become  a  Military  Standard  in  January  1 985? 

Yes  -  9  No  -  3  Later  -  9 

•  Should  the  KITIA  offer  to  sponsor  the  ARTEVG/RUNPG? 

Yes  -  1 3  No  -  7  Abstain  -  2 

e  Should  the  KITIA  lobby  for  a  "CAfS'ed"  UNIX  in  guasi-public  domain  (a  la  Berkley)? 

Yes  -  18  NO -3  Abstain  -  1 

•  Should  the  CAIS  become  a  Military  Standard  in  January  1 985? 

Yes  -  5  No  -  1 7  Abstain  -  1 

e  Should  the  CAIS  become  a  Draft  ML-STD  in  January  1985  7 
Yes  -  17  No  -  6  Abstain  -  0 

7.  MEETING  ADJOURNED 


17  July  1984  -  Joint  KIT /KITIA  Meeting 
1 .  Tricia  Obemdorf,  KIT  chairperson ,  brought  the  meeting  to  order. 


2-18 


t. 


2.  GENERAL  BUSINESS 

•  The  following  new  members  of  the  KITIA  were  welcomed :  Michael  Horton  (SDC) ,  Mike  Kamrad 
(Honeywell),  and  Charlie  Pow  (Lockheed).  Paul  Riley  (Data  General)  and  Kathy  Gilroy  (Harris) 
were  invited  guests. 

e  Texas  Instruments  is  responding  to  an  RFQ  for  extension  to  allow  the  AM  implementation  to 
proceed  using  the  Ada  Development  Environment.  CAIS  type  interfaces  are  also  being  analyzed. 

A  contract  mod  is  in  progress  to  TRW  to  continue  support  until  the  RFP  for  the  NOSC  support 
contract  is  available.  The  CAIS  Version  2  Design  RFP  is  in  contracts  for  release  for  a  potential 
January  award. 

e  Herm  Fischer  summarized  the  results  of  the  preceding  night's  KITIA  meeting  including  the 
results  of  the  KITIA  ballot  (presented  above). 

•  Jinny  Castor  reported  on  the  Evaluation  and  Validation  program  (see  handout).  The  E&V 
Quarterly  report  is  now  available.  A  procurement  for  CAIS  Validation  work  is  expected  in 
August. 

•  Ada  Europe  is  producing  a  MAPSE  selection  guide  following  the  format  of  the  compiler 
selection  guide.  The  MAPSE  selection  guide  may  be  available  by  the  end  of  the  year. 

3.  WORKING  GROW  REPORTS 

e  R  AC  VG 

-  Sections  2&3  received  abot  90$  approval  and  sections  3&7  about  70$  approval  at  the 
April  meeting.  Sections  4&6  are  expected  to  be  baselined  this  quarter.  Draft  rationales 
for  Sections  4&5  are  in  progress.  Expect  a  votable  RAC  for  the  next  meeting. 

•  CAISWG 

-  Expect  a  Version  1 .3  to  be  completed  in  this  quarter.  Mandatory  and  discretionary 
access  control  have  been  added.  The  CAIS  has  been  reformatted  to  comply  with 
MIL-STD  document  format.  Better  semantics  have  been  provided  with  additional 
clarification  of  the  node  and  process  models.  Responses  to  previous  CAIS  comments  are 
being  formulated.  A  second  Public  Review  of  the  CAIS  is  scheduled  for  Hyannis  at  *he 
SIGAda  meeting.  A  CAIS  Panel  was  conducted  at  the  Ada  Europe  meeting  our  mg  .*nich 
valuable  feedback  was  received. 


•  DEFWG 

-  Drafted  and  submitted  for  review  a  draft  Glossary  for  use  in  KIT  /KITIA  documents 
which  will  be  published  in  the  Public  Report.  The  definitions  pool  will  be  moved  to  ECLB 
for  KIT  /KITIA  access.  Additions  to  the  pool  to  include  STONEMAN  cited  terms  will  be 
added  in  the  next  quarter. 

•  STONEWG 

-  A  STONEMAN  Analysis  Report  and  a  Status  Report  were  provided  for  the  Public  Review 
The  Status  Report  contains  an  outline  for  a  revised  STONEMAN  document.  A  copy 
resides  on  the  KIT- INFORM  AT  ION  account  and  comments  are  requested 

•  STANDVG 

-  Reviewed  existing  standards  for  comparison  to  the  CAIS.  Expect  future  work  to  be 
merged  with  the  COMPVG  efforts 
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•  COMPWG 

-  Preparing  a  drift  CA/S  versus  RAC  analysis.  Plan  to  define  >  CA iS  semantics 
description  technique,  develop  a  Guidelines  and  Conventions  for  implementors,  arid 
complete  a  STONEMAN  versus  RAC  analysis. 

e  GACWG 

-  Drafted  “A  User’s  Guide  to  Ada  Transportability "  outline.  Expect  to  have  a  draft  for 
review  for  the  October  meeting.  Continuing  problem  of  availability  of  personnel 

4.  GENERAL  ANNOUNCEMENTS 

•  Judy  Kemer  advised  the  KIT /KITI A  that  IEEE  has  a  working  group  on  Ada  as  a  POL.  A  draft  of 
their  work  is  expected  to  be  available  at  the  August  SIGAda  meeting. 

e  Hal  Hart  reminded  the  members  about  the  Future  APSE  Workshop  scheduled  for  Santa  Barbara 
in  September  and  that  AdaTEC  has  been  elevated  to  a  Special  Interest  Group  and  is  now  SIGAda. 

e  Tricia  Obemdorf  reported  on  the  following  topic's : 

-  The  latest  Public  Report  is  in  reproduction  for  distribution. 

-  As  a  result  of  the  May  Tri-Service  review  the  ST  ARS  program  is  looking  to  strengthen 
the  area  of  software  reliability  and  may  have  FY-85  funding  to  support  this  effort. 

-  A  CAIS  Implementors  Group  (C!G)  has  been  formed  and  held  its  first  meeting  in  San 
Diego  (hosted  by  Data  General).  Rebecca  Bowerman  (MITRE)  was  elected 
chairperson  and  plans  future  meetings  in  Hyannis  and  Washington  D  C.  This  group 
expects  to  generate  some  point  papers  for  AJPO  based  on  the  results  of  their 
implementation  efforts.  This  group  is  independent  of  the  KIT /KITIA  and  is  basically 
composed  of  CAIS  implementors.  Contact  R.  Bowerman  for  additional  details. 

-  Hank  Steubing  of  the  JSSEE  will  make  available  their  “Operational  Concept  Document " 
for  review  and  feedback. 

-  A  second  Public  Review  of  the  CAIS  will  be  held  at  Hyannis,  MA  with  emphasis  on 
feedback  from  the  audience  on  the  major  features  of  the  document  such  as  the  node 
model,  process,  I/O,  and  non-technical  issues.  Working  groups  in  each  of  these  areas 
will  be  formed  to  address  specific  topics  and  formulate  recommendations.  The  emphasis 
win  focus  on  the  concepts  rather  than  specific  details. 

-  There  win  be  a  meeting  of  the  Runtime  Planning  Group  Thursday  evening  and  Friday ; 
contact  A.  Gargaro  for  details  as  attendance  is  limited. 

-  Bob  Mathis  and  the  AJPO  are  interested  in  comparing  the  CAIS  and  different  operating 
systems;  any  analysis  previously  performed  is  welcomed. 

-  The  future  meeting  schedule  stands  as : 

-  1 984  Oct.  1  -4  in  Merrimac  NH 

-  1985  Jan.  14-17  in  San  Diego 

Apr.  15-18  in  WasMngton  DC. 

Jul.  8-1 1  in  San  Francisco  area 

Sep.  23-26  in  Rhode  Island 
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-  1 9*6  Jan.  J  3-1 6  in  Sift  Diego 

Apr.  14-17  in  Atlanta 

Jul.  7-1 0  to  be  determined  (Schenectady ,  NY) 

Sap.  22-23  to  ba  determined  (Twin  Cities,  MN) 

-  1987  Jan.  19-22  San  Diego 

4.  BREAK 

5.  TECHNICAL  REPORTS 

a  Tom  Conrad  (NUSC)  raportad  on  tha  status  of  tha  Joint  Sarvica  Softwara  Engineering 
Environmant  plans  for  development  of  a  Plan  of  Action  and  Milastonas  (POAM)  and  an 
Oparational  Concapt  Documant  (OCD)  as  tha  high  laval  planning  documants  for  tha  Soft  vara 
Enginearing  Institute  (SEI).  The  SEI,  which  is  expected  to  ba  announced  in  tha  fall,  will  be 
responsible  for  implementing  the  requirements  formulated  by  tha  JSSEE. 

a  Dennis  Cornhill  (Honey  wall)  presented  results  of  their  experiences  with  Ada  for  distributed 
targets.  Their  goal  was  a  realization  of  an  “Ada  machine"  through  the  integration  of  a  number  of 
heterogeneous  processors.  Tha  methodology  was  to  complete  a  detailed  partitioning  of  software 
prior  to  the  detailed  design  phase.  The  partitioning  was  based  on  packages,  subprograms,  named 
blocks,  tasks,  objects  (variables,  constants,  etc.)  and  instantiations  of  generic  units.  It  was 
found  that  a  preliminary  functional  partitioning  was  required  before  the  detailed  design  phase. 
Con  figuration  control  during  tha  functional  allocation  phase  was  maintained  by  basing  tha 
configuration  change  on  the  accepted  partitioning  change.  The  partitioning  was  made  on 
application  functional  boundaries. 

a  Bernie  Abrams  (Grumman)  raportad  on  a  survey  conducted  for  ST ANDWG  to  see  if  the  CAiS  is 
conflicting  or  redundant  with  existing  standards.  The  results  were  that  although  there  are  a 
number  of  organizations  that  issue  standards  (ANSI,  ANS,  DoD,  FIPS,  IEEE,  ML-STD)  there  is 
presently  no  standard  comparable  to  the  CAIS.  The  closest  document  may  be  the  ANSI  3XH1 
Operating  System  Command  &  Response  Language  effort  that  is  ongoing. 

a  Rudy  Krutar  raportad  on  tha  construction  of  a  schema  for  maintenance  of  definitions  in  a  pool 
for  the  DEFVG.  Queries  can  be  obtained  for  sources  which  will  list  terms  or  for  the  glossary 
which  lists  tha  glossary.  A  standard  data  entry  format  has  been  identified. 

6.  BREAK  FOR  LUNCH. 

7.  RAC  DISCUSSION. 

a  Tim  Lyons  (Softwara  Sciences  Ltd.)  gave  presentations  on  tha  level  of  tha  CAIS  interfaces  and 
the  merger  of  database  and  filing  system  concepts.  A  transcript  of  these  presentations  is  to  be 
made  for  KIT /KITIA  availability . 

a  Hal  Hart  (TRW)  summarized  the  Requirements  and  Criteria  (RAC)  efforts  and  distributed  a 
copy  of  the  latest  RAC  Section  4  contents.  Issues  for  consideration  include  exact  names  versus 
exact  identifiers,  data  integrity  area  definition  and  consistent  terminology . 

8.  REORGANIZE  INTO  WORKING  GROUPS. 


.  * 


'j 


Wednesday ,  1 8  July 

9.  CONTINUE  WORKING  GROUPS 
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JO.  CONTINUE  RAC  DISCUSSIONS 


•  Frank  Belz  (TRW)  summarized  current  requirements  for  data  management.  These  include 

-  a  means  of  retaining  data 

-  a  means  of  creating  and  operating  on  data 

-  a  description  of  data  (which  mag  be  operated  upon) 

-  a  separation  of  relationships  and  properties  from  both  their  existence  and  the  tools  that 
operate  on  them 

-  a  wag  to  develop  new  data  bg  inheriting  properties  of  existing  data 

11.  ADJOURN  FOR  DAY 


Thursday,  19  Julg 


12.  CONTINUE  WORKING  GROUP  MEETINGS. 

IS.  TECHNICAL  PRESENTATIONS 

•  Andg  Rudnrrik  (GTE)  presented  the  status  of  their  work  on  a  Distributed  Software  Engineering 
Control  Process.  An  integral  part  of  this  effort  required  definition  of  an  interface  set 
comparable  to  the  CAIS.  Analysis  results  thus  far  indicate  the  CAIS  interface  level  is  the  most 
appropriate  for  implementation.  This  project  now  has  a  working  prototype  with  approximately 
300  packages. 

e  Frank  Belz  (TRW)  presented  the  status  of  the  Prototype  Advanced  APSE  task  being  performed 
for  the  Naval  Ocean  Systems  Center  (NOSC).  This  task  calls  for  a  prototype  implementation  of 
CAIS  interfaces  and  integration  of  selected  tools  utilizing  these  interfaces.  The  host 
environment  is  a  VAX/UNIX  system.  Results  of  this  effort  will  be  provided  to  NOSC  for 
consideration  bg  the  CAISVG. 

e  Jack  Kramer  (Institute  for  Defense  Analyses)  chaired  a  summary  of  current  changes  to  *he 
CAIS  and  future  directions  for  expansion. 


14.  KITIA  MEETING. 

o  Herm  Fischer  (Litton),  KITIA  chair,  conducted  a  KITIA  meeting.  KIT  members  were  invited  to 
attend.  Herm  reviewed  the  previously  voted  issues  and  discussed  the  benefits  of  a  "CAIS  d 
UNIX"  implementation  which  could  be  accomplished  in  various  ways  including  AJPG  contracts  or 
grants  to  universities.  Herm  suggested  the  KITIA  should  look  to  future  directions  as  a  group 
possibkj  considering  the  areas  of  methodology ,  risk  reduction  or  prototype  development. 
Subsequent  discussion  by  the  KITIA  recommended  formulation  of  a  risk  reduction  proposal  for 
submission  to  the  AJPO. 

13.  BREAK  FOR  LUNCH. 

16.  REORGANIZE  WTO  WORKING  GROUPS. 

17.  WORKING  CROUP  REPORTS. 

•  STONEWG  -  Herb  Willman  (Raytheon)  will  be  joining  this  group  which  will  continue  its  work  on 
formulation  of  a  STONEMAN  II  document. 

e  GACWG  -  plans  to  expand  its  outline  of  a  Guidelines  and  Conventions  document. 
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•  RACVG  -  expects  to  obtain  consensus  on  RAC  Sections  4-6  >n  August. 

•  DEFVG  -  solicited  KIT/KITIA  support  for  commonality  of  terminology  among  KP7K1T1A 
documents  and  reguested  member  input  via  NET  for  expansion  of  definition  pool. 

e  COMPWG  -  will  continue  analysis  of  the  CAIS  versus  the  RAC  documents  to  help  identify  any 
inconsistencies  between  these  documents.  Also  expects  to  initiate  work  in  conformance  areas 
and  to  identify  related  policy  and  technical  issues. 

e  ST ANDWG  -  will  continue  work  in  specification  analysis. 

18.  CLOSING  REMARKS. 

e  Herm  Fischer  (Litton)  indicated  the  results  of  the  KIT  I A  vote  for  future  direction  supported  the 
risk  reduction  proposal. 

e  No  major  problems  were  identified  with  the  April  meeting  minutes. 

•  KIT/KITJA  gratitude  was  expressed  to  Lucas  MagHeri  (National  Defense  Headquarters ,  Canada) 
for  a  superb  job  as  meeting  host. 

19.  MEETING  ADJOURNED. 
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ENDEES:  See  APPENDIX  A 


CPOBER  1984  -  JOINT  KET/KITIA  MEETING 


GENERAL  BUSINESS 

•  Introduction  of  visitors  and  new  representatives  were  made. 

•  Observers  from  Los  Alamos  vere  welcomed.  Los  Alamos  is  pursuing 
a  CAIS  implementation  on  Unix. 

s  Evaluations  of  the  bids  for  the  KIT  Sipport  contract  have  been 
completed. 

e  The  AIM  contract  has  been  extended  for  eight  to  nine  months. 

•  An  E&V  procurement  for  support  of  the  team  is  imminent, 
s  DIANA  maintenance  has  been  contracted  to  Intermetrics. 


NAMED  WORKING  GROUP  REPORTS 
e  GAISHG 

Jade  Kramer  announced  John  Long  of  TRW  is  now  supporting  Idle  CAIS 
effort  at  I.D.A.  Completed  projects  this  quarter  were  the  CAIS 
version  1.3  and  the  AdaTEC  CAIS  review  in  Hyannis.  Revisions  have 
begin  on  CAIS  1.3  to  complete  version  1.4  for  next  quarter.  CAIS 
version  1.4  is  due  for  typeset  in  January  and  will  be  delivered  to 
Bob  Mathis.  Presentations  for  next  quarter  are  a  status  of  the  CAIS 
document  as  a  military  standard  and  progress  on  the  accompanying 
rationale.  Jack  also  requested  additional  help  to  work  with  Tim 
Harrison  on  the  I/O  section  of  the  CAIS. 


RftCWG 

Sections  4,5,  and  6  of  the  RAC  document  were  scheduled  for  a  vote, 
but  section  4  was  deferred  until  next  quarter.  Also  an  action  item 
fnem  the  July  meeting  was  raised,  stating  that  the  gzxxp  was 
dissatisfied  with  the  treatment  of  security.  The  group  extracted 
functional  requirements  from  the  "orange  book"  and  stated  that  the 
RAC  nomenclature  was  inconsistent  with  definition  of  terms  in  the 
"orange  book".  Projected  work  includes  obtaining  approved  sections  of 


all  requirements  chapters,  vhich  will  be  attached  to  the  CAIS  Version  2 
RFP.  Also  planned  is  a  more  formal  procedure  for  configuration  management 
and  the  development  of  a  rationale  for  the  RAC. 

•  DETWG 

Due  this  quarter  was  a  combined  glossary  and  an  inclusion  of  STCNEMAN 
terms.  Completed  work  includes  a  definition  tool  on  ECLB  and  a  review  of 
the  glossary  over  the  ARPANET.  Projected  work  includes  adding  STONEMAN 
terms  to  the  glossary  when  a  revised  version  of  STCNEMAN  is  complete, 
opening  a  definition  tool  on  the  ARPANET  for  use  by  other  team  members, 
and  a  requirements  and  criteria  glossary  update.  A  presentation  is 
scheduled  for  next  quarter  on  using  the  definition  tool.  Other  actions 
include  a  decision  that  "orange  book"  definitions  take  precedence  over 
all  other  definitions. 


e  STCNEWG 

Ann  Reedy  discussed  the  items  due  this  quarter  vdiich  included  a  revision 
of  a  very  rough  draft  of  STCNEMAN  II  and  to  review  the  tool  set  section. 


•  GACWG 

Ron  Johnson  expressed  difficulty  with  availability  of  personnel,  which 
has  been  slowing  the  progess  on  drafts  for  al'  -hapters  of  "A  User's  Guide 
to  Ada  Transportability" .  The  group  expanded  resources  to  include  other 
guides  and  conventions  and  are  currently  working  on  detailed  outlines  of 
these.  Projected  work  for  next  quarter  is  editing  and  ccnpleting  all 
chapters  of  the  guide  and  a  description  of  the  user's  guide.  Tricia  stated 
the  possibility  that  some  CAISWG  members  might  support  the  GACNG  during 
the  next  quarter. 


•  OCMFWG 

Tim  Linguist  focused  an  a  draft  on  standards  related  to  the  CAIS  and 
discussed  CAIS  aonfbrmance  and  semantics. 


GENERAL  ANNOUNCEMENTS 

•  Tricia  noted  the  absence  of  San  Diego  TW  representatives,  considering 
that  Jack  Poidl's  daughter,  Andrea,  had  recently  undergone  heart  surgery, 
and  suggested  sending  a  post  card  to  her. 

•  Please  check  master  KTT/KITIA  address  listing  and  make  any  necessary 
corrections. 

e  Susan  Good  is  now  Susan  Ferdman  and  is  working  in  Philadelphia  as  a 
consultant  for  the  CAIS  until  the  middle  of  this  month. 

•  There  have  been  obvious  problems  with  ECLB,  due  to  moving  the  machine, 
vhich  farced  the  utilization  of  a  much  slower  circuit.  When  the  M3XNET 
is  qp  again,  the  new  host  address  will  be  26.7.0.65. 


•  SIGAda  elections  results  indicate  Anthony  Gargaro  is  the  new  SIGAda 
chairperson  and  Hal  Hart  is  the  vice-diair  for  Liaison. 

•  Our  contents  on  the  JSSEE  OCD  were  received.  The  chairperson.  Hank 
Stuebing,  enphasized  that  the  fCTT/KITIA  should  be  av«re  of  t*o 
inportant  points: 

a.  The  OCD  is  a  user's  view  of  SEE,  and  any  reference  to  implement¬ 
ation  is  only  for  illustration. 

b.  Also,  the  OCD  is  not  a  fbllow^-cn  to  the  STCNEMAN,  since  the  OCD  is 
a  user's  view  of  SEE  and  STCNEMAN  is  an  implementor's  view  of  APSE 


e  A  Future  APSE  Workshop  was  held  in  Santa  Barbara  and,  although  the  CAIS 
was  discussed,  it  was  not  the  focal  point.  Ehphasis  vets  more  on  a 
parallel  with  JSSEE  and  a  user’s  view  of  advanced  capabilities.  All 
working  group  chairs  are  coordinating  reports  of  working  groups' 
discussions  and  a  sumary  should  be  contained  in  a  special  Ada  letters 
sometime  in  the  spring. 


1.  MEETING  SCHEDULE 


1985 

January  14-17  San  Diego 

April  15-18  Washington  D.C. 

July  8-11  San  Francisco 

September  23-26  Rhode  Island 

1986 

January  13-16  San  Diego 

April  14-17  Atlanta 

July  7-10  Schenectady,  NY 

September  22-25  Minneapolis/ St.  Paul 

1987 

January  19-22  San  Diego 


5.  DEFINITIONS  AND  DISCUSSIONS 


e  "Orange  Book"  Glossary: 

It  was  determined  by  W32  that  the  definition  of  "object"  should  be 
changed  to  "entity"  throughout  the  RAC,  considering  the  fact  that 
the  "orange  book"  terms  have  precedence  over  all  other  definitions 
and  its  definition  of  "object"  did  not  mesh  with  the  group's  intended 
use  of  the  word. 

•  DEFWG  Terminology  Issue  Resolution: 

Jack  Kramer  reviewed  the  problems  with  terms  and  definitions  in  the 


glossary.  The  definition  of  "process"  was  discussed  in  reference  to 
the  "orange  book"  and  in  the  RAC.  Several  opinions  and  responses 
about  conflicts  in  definitions  were  expressed  and  an  effort  was  made 
to  determine  exactly  what  was  needed.  Tricia  asked  DEEVK3  to  obtain 
information  from  the  people  at  the  meeting  to  distinguish  the  terms 
and  definitions  and  also  to  design  a  procedure  for  collecting  and 
reviewing  these  terms. 


6.  SEPARATE  MEETINGS  CN  RAC  SECTIONS 


3  OCTOBER  1984 


7.  CMS  HYANNIS  REVIEW  REPORT 

•  Node  model  discussions  concentrated  on  standard  attributes, 
distributed  systems,  and  access  control. 

•  Process  model  discussions  emphasized  the  blocking/ nonblocking 
issue. 

•  Security  discussions  centered  on  the  need  for  a  consolidated 
approach. 

•  Input/Output  discussions  included  magnetic  tape  support, 
pracpnatics,  standards,  and  queue  nodes. 

•  Non- technical  discussions  centered  on  the  pros  and  cons  of 
military  standardization  according  to  the  current  schedule. 

8.  STRATEGY  DISCUSSIONS  WITH  06  'S  AND  BOB  MATHIS 

•  Tricia  welcomed  Bill  Wilder  of  the  Navy  representing  Captain  Bos  laugh. 

Bob  Mathis  (the  director  of  AJPO  and  SEARS),  Brian  Schaar  (the  Navy 
deputy  to  the  AJPO),  Gol.  Nidiffer  of  the  Air  Force,  and  Jim  Hess  of 
the  Army.  Discussion  began  with  the  CAIS  introduction  and  general 
strategies  for  furthering  the  Ada  program. 

•  Fran  the  Hyannis  Review,  concerning  the  original  plan  of  submitting 
a  military  standard  in  January  1985,  it  was  decided  to  submit  to  the 
AJPO  a  candidate  for  standardization  instead. 

•  Herm  Fisher  reviewed  the  discussion  of  the  July  meeting  and  the  major 
ideas  he  and  Eli  Lairb  expressed:  (1)  the  CAIS  draft  due  in  January 
should  not  be  standardized,  (2)  prototyping  should  be  the  next  object 
of  contracts,  (3)  Eli's  alternative  look  at  a  risk  reduction  contract. 

•  Key  issues  of  the  risk  reduction  contract  were  to  capitalize  on  industry' 
current  ideas  and  to  create  sane  type  of  CAIS  subset  to  be  oatpatible 
with  industry  and  allow  tool  transportability. 


•  Bob  Mathis  expressed  the  STARS  objective  to  develop  the  best  Software 
Engineering  Environment  (SEE)  by  the  end  of  the  drcade  in  two  pluses 
and  have  it  installed  on  a  service  project. 

•  The  majority  agreed  on  the  need  for  an  interface  standard,  however 
disagreements  arose  concerning  the  strategy  necessary  to  achieve  this, 
the  time  constraints  involved  considering  other  environments  being 
developed,  and  how  to  keep  industry's  support  and  interest  by  clarifying 
the  market. 

•  Rich  Thall  of  SofTech  suggested  a  proposal  for  advancing  the  Ada 
environment  standard  by  developing  two  parallel  standards:  (1)  the 
first  step  was  to  put  an  Ada  environment  on  top  of  an  existing 
operating  system  and  achieve  transportability  this  vay,  (2)  the  next 
issue  was  a  oonmun  APSE  operating  system  design  to  achieve  the  long 
term  goal  of  transportability  and  interoperability.  Rich  also 
discussed  the  pros  and  cons  of  using  the  already  existing  UNIX  system. 


•  Many  diverse  views  and  opinions  were  expressed  regarding  alternatives 
for  possible  conformance  policies,  including  CAXS  subsets  and/or 
supersets. 


9.  RAC  SECTIONS  4  &  5  Presentations/Discussions 

Tim  Harrison  reviewed  RAO  section  6  revisions.  A  vote  of  approval  was 
deferred  until  the  end  of  the  session,  along  with  votes  on  sections  4 
and  5.  Frank  Belz  discussed  RAC  section  4,  involving  data  management, 
typing,  identification,  operations,  transactions,  and  history. 

Results  of  balloting: 

Section  4  yes(21),  qualified  yes(15),  no(l),  abstain (2) 
Section  5  yes(26),  qualified  yes(8),  no(l),  abstain(l) 
Section  6  yes(24),  qualified  yes(ll),  no(l),  abstain(2) 


10.  JSSEE  review  by  Herman  Fischer. 


4  OCTOBER  1984 


11.  ST0NEW3  Presentation  -  Steve  Glaseman 


12.  ALS/CAIS  Study  Preliminary  Report  -  SofTech 


Rich  Thall  introduced  Rich  S inpeon,  Nancy  Yost,  and  Carl  Hitchon 
as  the  other  members  of  the  SofTech  team  that  is  focusing  on 
resolving  the  differences  between  the  ALS  and  CAIS,  and  designing 


a  strategy  for  an  ALS-to-CAIS  transition.  The  general  strategy  is 
to  a  CMS  KAPSE  on  top  of  an  ALS  interface  and,  alternatively, 

build  an  ALS  KAPSE  on  top  of  a  CAIS  interface.  The  group  has  ccnpleted 
a  draft  docanent  studying  these  ideas  and  is  approximately  halftmy 
through  with  the  project.  Rich  Sinpacn  dl aniseed  a  database  ocepariaon 
for  mapping,  followed  by  a  process  ocnparison  by  Rich  Thall. 
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KAPSE  Interface  Team 


INTRODUCTION 


Hie  second  Cannon  Ada  Programing  Support  Environment  (APSE)  Interface 
Set  (CAIS)  Public  Review  was  held  in  Hyannis,  MA  an  2  August  1964  in 
conjunction  with  the  AdaTBC  meeting  at  that  time.  Over  one  hundred 
participants  from  industry,  academia  and  government  attended.  the 
subject  of  the  review  was  Version  1.3  of  the  CAIS  document. 

Hie  CAIS  has  been  developed  by  the  CAIS  Mocking  Group  (CAISWG)  of  the 
Kernel  APSE  (KAPSE)  Interface  Teem  (KIT,  a  Navy-lead  DoD  team)  and  the 
KAPSE  Interface  Team  from  Industry  and  Academia  (KITIA,  it's 
industry/academia  counterpart)  for  the  Ada  Joint  Program  Office  (AJPO). 
These  teams  have  bean  meeting  since  early  1962  in  an  attenpt  to  define  a 
set  of  interfaces  which  could  be  inplemsnted  in  all  APSEs  in  order  to 
make  it  possible  for  APSEs  to  tiiare  tools  and  databases.  Hie  current 
version  of  the  CAIS  primarily  addresses  only  those  interfaces  needed  to 
share  tools. 

The  review  wee  preceded  the  previous  night  by  a  two-hour  discussion  of 
the  diangaa  that  have  been  mads  to  the  CAIS  interfaces  since  the  last 
Public  Review  (held  Septsnfcer  1963  in  Washington,  O.C. ) .  Consequently, 
an  the  morning  of  the  review,  only  a  short  presentation  was  given  an 
this  topic.  The  participants  then  organized  into  discussion  groups 
which  focused  on  five  areass  the  node  modal,  the  process  model,  the 
iiput/output,  the  security  model  and  non-tschnical  issues.  Hie 
summaries  of  the  discussions  held  by  these  five  groups  are  found  in  each 
of  the  following  five  sections.  Late  in  the  afternoon  everyone  mat  back 
together  to  hear  and  discuss  the  rapoarts  frcm  the  separate  groups. 

General  ocmuanta  reflected  that  there  has  bean  considerable  improvement 
in  the  document  since  the  Version  (1.0)  which  was  reviewed  in  September. 
The  seism  Lies  hsve  bean  addressed  more  completely  and  consistently. 
Sans  deficiencies  in  sans  sections  still  exist  and  were  pointed  out  by 
the  Byamis  reviewers.  All  of  the  models  have  matured;  the  node  model 
has  become  very  stable  (aside  from  the  introduction  of  security  and 
access  aontxol  mechanisms)  and  the  process  model  assmad  to  meet  with 
general  acceptance.  Much  work  remains  to  be  dons  on  the  input/output 
section,  but  many  helpful  auggaationa  for  directions  to  pursue  ware 
provided  by  the  reviewers,  and  the  next  version  ahould  show  maturity  in 
this  arse  as  well.  Very  few  of  the  catmints  received  indicated  that 
siyiif leant  interfaces  were  missing,  and,  of  those  raantionad,  most 
cannot  be  easily  provided  in  a  portable  manner. 


Overall,  the  session  was  very  well-attended  with  many  helpful  ocnroents 
and  much  useful  feedback  received.  The  participation  of  all  those 
present  was  very  impressive,  especially  considering  that  the  document 
had  only  been  made  available  to  most  attendees  the  day  before  the  review 
meeting.  The  suggestions  presented  were  sound  and  showed  a  great  deal 
of  insist  into  the  objectives  of  the  task  in  general  and  the  design 
goals  of  the  CAIS  in  particular.  The  attendees  are  all  to  be  highly 
praised  far  this  one  day  of  work,  and  their  contributions  are  all 
greatly  appreciated  by  the  AJPO,  the  KIT,  the  EdTIA  and  the  CAISWG. 

The  CAISWG  is  now  diligently  working  its  way  through  the  many  ocnments 
and  discussions  and  is  drafting  a  now  version  of  the  document.  This 
version  will  be  presented  to  the  KIT  and  KITTA  at  their  October  meeting. 
The  ocnments  received  there  will  be  the  im  jar  inputs  to  an  intensive 
one-week  CAISWG  meeting  two  weeks  later.  That  meeting  will  result  in  a 
new  draft  1.4  of  the  CAIS  vftiich  will  be  mailed  early  in  November  to  all 
participants  in  the  Hyannia  review  and  anyone  else  requesting  a  copy. 
That  version  will  be  the  subject  of  review  meetings  to  be  held  in 
Washington,  O.C.  in  aon junction  with  the  SIGAda  meeting  26-30  November. 
Final  ocnments  must  be  received  by  7  December,  as  the  CAISWG  is 
scheduled  to  deliver  the  draft  CAIS  to  the  Ma  Joint  Program  Office 
(AJPO)  in  mid-January  1965.  This  draft  will  be  the  one  proposed  for 
military  standardization,  and  its  delivery  to  the  A7F0  in  January  will 
signal  the  initiation  of  a  full  tri-service  coordination  for 
standardization. 

Many  comments  about  the  CAIS  have  been  made,  both  publicly  in  journals 
such  as  Ada  Letters  and  privately.  The  KIT,  the  KITIA,  the  CAISWG  and 
the  AJPO  constantly  invite  all  those  *bo  hold  opinions  on  the  CAIS  to 
make  those  opinions  and  the  reasons  for  than  known  to  us.  Anyone 
wishing  to  participate  in  the  November  review  vbo  did  not  receive  a  copy 
of  CAIS  1.3  should  make  sure  they  will  receive  Version  1.4  by 
contacting; 

Patricia  Obemdorf 
Code  423 
NOSC 

San  Diego,  CA  92152 
(619)225-6682 
POBEBMDOKF@BCLB 

Even  if  you  are  unable  to  attend  the  November  review,  be  sure  that  your 
comments  (including  the  rationale  behind  them)  are  sent  either  to  the 
above  address,  to  the  address  in  tha  back  of  the  document  or  to 
CAIS-OOMMEWT@ECLB  on  the  ARPANET.  The  final  cutoff  date  for  all 
omnents  regarding  CAIS  Version  1  is  7  December  1984.  WS  appreciate  the 
participation  of  each  and  every  one  of  you,  and  we  look  forward  to 
hearing  from  you  in  the  future. 


3-2 


SECTION  1:  NODE  MODEL  DISCUSSION  GROUP 

The  mi n  topics  addressed  by  the  discussion  groqp  on  the  node  model 


a)  seaport  for  distributed  implementations 

b)  concerns  of  intra-  and  interoperability  of  tools 

c)  the  interrelation  of  KAPSE/CAIS/Bm-tirae  Environment 


Several  other  issues  regarding  specific  concepts  of  the  CA1S  were 
discussed,  and  recommendations  for  further  refinements  of  the  QMS  were 


The  general  atmosphere  o*  the  discussion  was  one  of  contentment  with  the 
concepts  of  the  current  nods  model,  mixed  with  concerns  about 
implementation  and  efficiency  aspects  on  distributed  systems.  There  was 
a  uniform  expression  of  ths  need  to  expend  the  CATS  in  the  area  of 
predefined  attributes  and  relationships. 

1.  The  OOS  mat  provide  support  for  distributed  environments. 

Given  the  clear  trend  toward  distributed  systems  of 
vrarkstations  as  the  system  configuration  for  program 
development,  there  is  much  concern  about  the  inplementability 
and  the  appropriateness  of  ths  CAIS  for  such  distributed 
systems. 

TVo  situations  must  be  distinguished* 

-  a  single  CAIS  implemented  an  top  of  a  distributed  system, 
and 

-  oamsunication  between  CAIS  implementations  an  different 
acnponents  of  a  distributed  system. 

With  regard  to  the  former,  the  issues  of  ocnnunication  among 
the  system  ocnpcnents  are  largely  hidden  within  the  CAIS,  which 
is  free  to  implement  whichever  oonmmication  mechanism  appears 
most  appropriate.  Likewise,  the  distribution  of  the  CAIS  nodes 
among  various  servers  or  their  administration  at  a  central 
server  are  problems  that  need  to  be  solved  by  the  CAIS 
implementor,  rather  than  at  the  CAIS  interface  level. 
Currently,  the  CAIS  has  no  known  deficiencies  that  would 
preclude  either  implementation.  There  is,  however,  a  need  for 
reeouroe  ocntrol  mechanisms  within  the  CAIS  to  allow  the  user 
to  exercise  control  over  vhich  system  components  are  tasked  to 
perform  activities  on  his/her  behalf.  These  interfaces  fall  in 
ths  category  of  deferred  CAIS  issues,  mainly  because  the  nature 
of  such  interfaces  is  as  yet  uncertain.  Nevertheless,  their 
importance  has  to  be  acknowledged  and  work  to  define  such 
interfaces  should  be  started  as  soon  as  feasible. 


With  regard  to  aanmaiication  between  different  CAIS 
implementations,  two  levels  need  to  be  distinguidtadt 

-  the  "physical”  mechanisms  for  ocnruiication 

-  the  interoperability  between  tools  residing  on  different 
CAIS  implementations. 


These  issues  are  not  tnique  to  systems  consisting  of 
distributed  workstations,  but  also  arise  in  general,  «hm  data 
and  tools  are  to  be  exchanged  between  different  CAIS 
implementations. 


With  regard  to  the  oomnuni  cation  mechanism,  two  proposals  were 
made: 


a.  The  ISO  Model  should  be  examined  as  a  possible  basis  for 
ocnmon  communication  interfaces  between  CAIS 
implementations.  If  this  examination  determines  that  the 
model  is  adequate,  CAIS  interfaces  should  be  added  that 
reflect  the  various  levels  of  the  ISO  Model. 

b.  There  is  an  urgent  need  for  the  specification  of  an 
external  farm  for  nodes,  attributes,  and  relationships, 
very  much  like  the  specification  of  an  external  form  for 
DIANA,  so  that  node  structures  can  be  exchanged  between 
different  CAIS  implementations,  given  CAIS-specific  reader 
and  writer  programs  for  this  external  representation. 


There  were  concerns  regarding  inter-  and  intraoperability. 

There  vms  a  general  opinion  in  the  working  group  that  the  CAIS, 
ae  currently  defined,  provides  little  support  that  would 
enhance  the  interoperability  or  intraoperability  of  tools, 
since  very  few  of  the  attributes  and  relationships  important 
for  ccnmunication  among  tools  are  predefined  by  the  CAIS.  The 
CAIS,  in  order  to  be  true  to  its  objectives,  must  include  such 
aannonly  defined  attributes  and  relationships.  As  a  concrete 
step  tonferd  this  goal,  msnhers  of  the  working  groip  agreed  to 
send  iraocrmendations  for  such  attributes  and  relationships  to 
the  MONET  account  GAIS-aY*EOT@ECI£;  the  public  at  large  is 
invited  to  do  so  as  well.  While  CAIS  1.3  provides  a  framework 
for  the  terminology  used,  CAIS  2.0  should  define  a  substantial 
set  of  attributes  and  relationships  with  predefined  meanings. 
As  an  interim  solution,  agreement  on  ocnmon  attributes  and 
relationships  aould  also  be  reached  among  the  members  of  the 
CAIS  Implementors'  Groip,  vhich  should  be  a  prims  source  of 


valuable  contributions 


It  was  pointed  out  that  the  objective  of  CMS  1.3,  apart  from 
providing  a  general  framework,  was  mainly  to  support 
portability  of  closed  tool-sets,  i.e. ,  sets  of  tools  with 
coordinated  information  interfaces  between  themselves,  but  with 
little,  if  any,  dependency  on  data  interfaces  with  other  tools 
present  in  the  APSE.  Predefining  certain  attributes  and 
relationships  often  infringes  on  issues  of  the  methodology  of 
the  tool  support  far  a  given  activity.  It  was  therefore  felt 
by  the  OtlSHG  that  sudi  attributes  and  relationships  can  be 
predefined  only  with  the  widest  possible  participation  of 
current  and  future  CMS-  and  APSE-iitplamentora . 


3.  Mat  is  the  interrelation  of  (AIS/KAPSE/ftn-Time  Bwironeemt? 

A  lengthy  discussion  dealt  with  the  interrelation  of  the  CAIS 
with  the  STCNEMAN  KAPSE  model  and  with  the  Run-Time  Environment 
of  Ada  programs.  This  discussion  showed  the  diversity  of 
perceptions  of  what  constitutes  a  STCNEMAN  KAPSE  and  how  the 
CAIS  relates  to  this  model  (a  phenomenon  that  has  already  been 
observed  in  discussions  of  KTP/KrriA,  which  eventually  led  the 
GAISHG  to  an  approach  that  avoided  mentioning  the  concept  of  a 
KAPSE  at  all).  It  was  reuonmended  that  a  list  of  STONEMAN 
KAPSE  features  not  supported  by  the  CAIS  be  provided,  in  an 
atteept  to  delineate  the  distinction  between  the  CAIS  and  the 
SRW BON  KAPSE. 

It  was  then  Observed  that  many  of  the  interfaces  of  the  CAIS 
bear  a  strong  resemblance  to  interfaces  required  far  the 
run-time  support  of  Ada  programs,  vrtiich  brought  up  the  question 
of  whether  the  CAIS  should  recognize  and  iixjorporate  these 
interfaces  as  well.  Such  an  approach  would  enable  inplemantors 
to  integrate  their  inplementation  of  the  run-time  environment 
with  the  CAIS.  It  wes  pointed  out  that  the  countar-ajrcpment  to 
such  an  inclusion  in  the  CAIS  1s  three-fold.  Firstly,  the 
inclusion  would  expand  the  CAIS  beyond  its  scope  of  providing  a 
basis  for  porting  program  development  tools  among  APSEs. 
Secondly,  the  inplemantors  today  can  already  take  advantage  of 
the  Gcranonalities  and  base  both  the  CAIS  and  the  Ada  run-time 
environment  on  the  same  indarpinnings;  there  is  no  immsdiate 
nead  foe  a  CAIS  to  praacriba  such  inplementation  ocranonality. 
Thirdly,  an  encroachment  of  the  CAIS  into  the  area  of  run-time 
environments  would  almoet  certainly  make  existing  compilers  and 
their  inplenmntation  of  the  run-time  environment  incompatible 
with  the  CAIS.  (For  the  latter  reason,  the  GAISNG  has 
studiously  triad  to  avoid  inposing  requirements  on  the  run-time 
environment  that  could  not  be  expected  to  be  an  iiimediate 
ooneequanca  of  Ada  semantics  or  satisfiable  in  any  reasonable 
iaplementation  of  the  Ada  run-time  environments. )  One  argument 
that  was  also  discussed  was  that,  if  that  interconnection  was 


nmAm  explicit  in  the  CMS,  the  CMS  could  be  much  more 
"imperative"  about  run-tine  iaeues  (as  opposed  to  the  current 
approach  of  "don't  hurt  existing  implementations "  ty  putting 
requirements  an  them).  The  results  were  inconclusive;  opinion 
was  divided  as  to  whether  or  not  this  should  be  done. 


4.  There  is  over  the  potential  efficiency  of  piggybacked 

Seme  concern  was  expressed  over  whether  CMS  implementations  on 
top  of  existing  operating  systems  would  be  efficient  enouepi  to 
meet  the  needs  of  tools.  While  there  cannot  be  a  conclusive 
answer  to  this  question  before  pilot  inplemantations  have 
provided  us  with  empirical  data,  it  is  to  be  expected  that  acme 
overhead  cost  is  to  be  paid  for  the  transformation  through 
multiple  layers.  On  the  other  hand,  if  the  added  support 
provided  by  the  node  model  is  appropriate  far  many  tools,  then 
one  can  surmise  that  existing  tools  of  this  flavor  are  already 
paying  the  same  overhead  for  administrating  their  internal  data 
representations.  Henoe,  if  these  tools  were  to  use  the  CMS 
interfaces,  instead  of  having  their  own  but  similar  data 
administration,  their  overall  performance  is  likely  to  improve, 
since  the  CMS  implementor  can  exploit  underlying  system 
features  generally  not  available  to,  or  not  used  by,  existing 
tools.  Efficiency  of  the  CMS  should  not  be  measured  by  its 
own  efficiency,  but  rather  by  the  efficiency  of  the  tools  based 
on  the  CMS  aenpared  against  similar  tools  without  CMS 
support. 

One  area  in  vtfulch  the  CMS  may  cause  undue  loss  of  efficiency 
is  the  area  of  revision  control.  Currently,  the  CMS  has  no 
built-in  mechanisms  for  revision  control.  Instead,  it  provides 
the  primitives  required  to  implement  ary  number  of  different 
revision  control  schemes.  This  implies  that  tools  must  first 
go  through  the  revision  aontrol  layer  before  reaching  the  CMS 
layer  and  the  operating  system  below  it.  A  CMS  implementation 
following  this  layered  scheme  cannot  employ  special  mechanisms 
for  speeding  up  this  particular  aspect  of  file  handling.  It 
wee  therefore  recommended  that  the  inclusion  of  a  revision 
model  in  the  general  node  model  should  be  examined. 


5.  The  CMS  needs  to  provide  a  transaction  concept. 

The  CMS  currently  does  not  provide  a  transaction  scheme  that 
allow  transaction  aontrol  beyond  the  life-time  of  a  single 
process.  It  was  reocnmended  that  transaction  control 
mechanisms  be  included  that  allow  transactions  to  span  over  the 
consecutive  execution  of  multiple  processes. 


6.  The 


and 


should  be 


The  CAIS  is  currently  predicated  on  an  administrative 
organization  that  considers  the  individual  user  as  a  focal 
point,  as  demonstrated  by  the  concepts  of  " curr ent_user ”  and 
"user”  relations.  However,  severed,  existing  operating  systems 
used  for  program  development  are  more  oriented  towards 
"projects'*  as  the  main  administrative  focus,  with  users 
connecting  or  logging  into  particular  projects.  Although 
"projects"  can  be  supported  in  a  GAIS  implementation  by 
considering  a  "project"  as  still  another  "user",  it  was 
reacmmended  that  the  terminology  of  "user"  be  changed  to  a 
terminology  less  biased  towards  a  particular  administrative 
view. 


SECTION  2:  PROCESS  MODEL  DISCUSSION  GROUP 

The  main  topics  addressed  by  the  discussion  group  on  the  process  model 
wares 

a)  parallel  execution  of  tasks 

b)  process  states 

c)  interrupts. 


The  general  tone  of  the  discussion  was  that  the  CAIS  process  model  is 
workable  end  not  far  from  its  goals.  The  carman  Is  were  of  the  nature  of 
specific  points  for  improvement,  with  the  underlying  assumption  that  the 
larger  lasuss  are  already  well  solved. 


1.  the  ability  af  tasks  to  exsnits  in  parallel  is  important. 

Several  ocnants  concerned  the  ability  of  tasks  to  execute  in 
parallel.  The  Ada  Reference  Manual  does  not  require  that 
parallel  tasks  actually  execute  simultaneously,  only  that  they 
proceed  independently,  except  at  points  vhere  they  syndvonize. 
The  aoasants  expressed  the  concern  that  code  written  with  the 
aeeueption  that  ana  task's  execution  will  NOT  block  the 
execution  of  another  tart  would  not  be  transportable  to  a  CAIS 
jjyl saentation  where  one  tart's  execution  DOES  block  the 
execution  of  another. 

The  participants  agreed  on  the  following  statement  as  a 
anaprcsrf.ee  between  a  desire  to  have  non-blocking  of  parallel 
tasks  and  the  reality  that  ccepilers  at  present  are  blocking. 
"The  goal  is  to  have  non-blocking  compilers,  but  the  assumption 
rtould  not  be  made  that  the  aapiler  is  non-blocking,  because 
in  early  l^pl  saltations  ocapilers  will  be  blocking.” 


v-v 


2.  Mace  states 


reporting 


status. 


Die  process  states  transition  table  given  in  Table  II  of  CAIS 
1.3  (pege  70)  does  not  shot/  hot/  a  process  is  created.  A  n a/ 
row  needs  to  be  added  for  the  operation  of  creating  a  process. 
A  new  aolunn  needs  to  be  added  for  processes  vhich  do  not 
exist,  in  order  to  make  the  state  transition  table  ccnplete. 

Seme  oemuents  concerned  a  wish  to  be  able  to  distinguish 
between  a  process  vAiidi  is  in  the  READ?  state,  but  which  is 
waiting  for  resources  or  rendezvous,  and  a  process  vhich  is  in 
the  READ?  state  and  is  actually  executing.  This  desire  stems 
from  a  need  to  monitor  the  progress  of  a  process. 

Some  oenments  concerned  the  ocnpleticn  status  enumeration 
values.  The  addition  of  the  value  COMBUSTED,  distinct  from 
ABORTED  and  TERMINATED,  was  suggested.  The  Ada  Reference 
Manual  describes  a  task  as  "ooqpleted  but  not  terminated"  if  it 
has  completed  the  execution  of  its  sequence  of  statements  but 
is  waiting  far  the  termination  of  a  child.  It  was  pointed  out. 
however,  that  CAIS  processes  are  closely  analogous  to  Ada 
programs,  which  may  include  many  tasks,  so  this  distinction  is 
not  appropriate. 


3.  Sobs  terminology  is  anfeiqaoas. 

In  the  description  of  the  semantics  of  ABORT_PROCESS  as  well  as 
other  places,  the  term  "descendant"  is  used.  There  is 
ambiguity  about  the  meaning  of  the  term.  Does  it  mean  "a 
process  I  created"  or  "a  process  I  am  the  parent  of"? 


4.  Internets  should  be  integrated  into  the  node  eodel. 

The  suggestion  was  made  that  the  receipt  of  a  signal  should  be 
able  to  change  the  priority  of  the  receiver.  However,  the 
benefit  gained  was  judged  not  to  warrant  the  csost. 

The  suggestion  was  made  that  processes  micfht  need  an  analogy  to 
the  terminate  alternative  for  Ada  tasks.  But  the  user  can 
design  it  using  existing  facilities,  so  it  is  not  needed  in  the 
CAIS. 

The  suggestion  was  made  that  the  CAIS  could  be  made  more 
consistent  if  the  interrupts  were  nodes  themselves,  just  as 
queues  are,  because  an  interrupt  is  a  named  entity  that  is  not 
currently  integrated  into  the  node  model. 
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5.  Mors  explicit  interaction  between  the  OIS  and  its  hardware 
(both  host  and  target)  was  railed  for. 

There  is  a  aoncern  that  the  underlying  hardware  nay  fail  and 
destroy  the  tree  structure  of  the  CAIS,  indicating  a  need  for  a 
mechanism  for  reporting  hardware  problems.  Howver,  this 
seemed  to  seme  participants  to  be  outside  the  scope  of  the 
CMS. 

There  is  a  desire  for  explicit  support  for  targets  and 
distribution,  so  that  the  user  or  tool  designer  can  have  eerne 
control  over  the  assignnent  of  processes  to  logical  processors. 


SECTION  3:-  INPUT/OUTPUT  DISCUSSION  GROUP 

The  main  topics  addressed  by  the  discussion  group  on  Input/Output  (I/O) 
were: 

a)  the  tape  standard  used 

b)  the  terminal  capabilities 

c)  status  information. 


The  general  atmosphere  of  the  discussion  indicates  that  the  I/O  section 
needs  substantial  modification  before  it  is  appropriate  to  establish  it 
as  part  of  a  MTL-STD.  There  were  a  large  timber  of  oemnents  dealing 
with  lade  of  clarity,  missing  interfaces,  inadequacy  of  interfaces, 
inconsistencies  and  other  deficiencies. 

1.  The  ues  of  a  different  magnetic  tape  standard  for  the  CMS 
■rriol  should  be  fwnniAifa^- 

Several  people  in  the  group  indicated  that  there  are  problems 
in  assenting  that  the  ANSI  tape  standards  can  be  used  to  define 
a  mechanism  for  transporting  source  code  from  one  APSE  to 
another.  In  particular,  they  sited  that  tape  drives  by 
different  manufacturers  deviate  slightly  from  the  standards, 
thus  making  them  inccnpatible.  It  was  also  noted  that  the  ANSI 
standards  cause  a  large  amount  of  tape  space  to  be  wasted. 

It  was  reoemmended  by  the  group  that  TCP  be  used  to  provide  for 
the  transporting  of  textual  data.  This  method  eliminates  the 
problem  of  defining  the  "exact"  positioning  of  data  on  magnetic 
media  ( inter-record  gaps). 
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problems  with  inconsistency 


It  was  noted  by  the  group  that  there  are  inconsistencies  among 
the  interfaces.  This  is  a  problem  that  deserves  touch  attention 
before  the  I/O  section  is  proposed  as  a  draft.  (They  noted 
that  the  different  sections  are  inconsistent  with  each  other  as 
well.)  The  interplay  between  GAIS_TEXT_IO  and  the  other  I/O 
packages  is  poorly  defined. 


3.  Queue  nodes  were  well-received. 

The  concept  of  queue  nodes  was  favorably  received.  In  fact, 
this  was  one  of  the  major  deficiencies  that  people  had  cane 
prepared  to  ocnplain  about. 


4.  Additional  interfaces  ware  proposed  to  artrtrwes  current 
deficiencies. 

Additional  interfaces  were  presented  as  neccessary  for  a  useful 
I/O  model.  Among  than  were  file  node  attributes  (file/queue 
size,  device  type,  terminal  class,  terminal  capabilities)  and 
host  buffer  control  (flushing,  forcing  to  disk). 


5.  Additional  terminal  owpahilitiwa  were  suggested. 

It  was  suggested  that  interfaces  be  provided  that  enable  a  user 
to  determine  (1)  which  function  key  has  been  pressed,  (2)  vhi<±i 
class  of  terminal  is  associated  with  a  particular  node,  and  (3) 
which  interfaces  are  "directly"  supported  by  the  terminal  being 
used. 

Get/Put  should  be  more  carefully  defined. 

Form  terminals  should  contain  a  "farm"  data  type  that  is 
manipulated  by  interfaces.  This  permits  several  "forms"  to  be 
in  existence  at  once. 


6.  There  is  a  desire  for  better  status  information  in  the  event  of 
failures. 

There  was  considerable  discussion  about  the  problems  of  trying 
to  reoover  from  I/O  operations  that  foil.  Exceptions  do  not 
provide  enough  information  for  a  programmer  to  inform  the  user 
of  his/her  program  what  actually  caused  the  I/O  operation  to 
foil.  There  is  a  need  to  provide  an  interface  that  can  obtain 
information  from  the  host  06  about  the  reason  fbr  the  failure. 
There  was  no  resolution  of  this  matter  as  no  "transportable" 


interface  could  be  determined 


7.  The  following  ■iecellapeoue  topics  wen  dieoneeed  only  briefly. 

*  Industry  standards  (e.g.f  GKS,  TCP-IP,  ISO  communications) 
should  be  considered  in  the  design  of  the  CAIS. 


*  The  byte  stream  used  in  TBCTJK)  should  be  recognizable.  That 
is,  the  OVIS  should  define  the  meanings  of  all  byte  sequences 
and  how  they  are  to  be  interpreted. 

*  A  single  file  should  be  defined  vpon  which  all  I/O  operations 
are  performed. 

*  Is  windowing  (like  on  a  USA)  possible  with  the  currant 
design?  (It  was  determined  by  the  group  that  it  could  be  done, 
but  would  be  hidden  within  the  iaplenmntation. ) 

*  There  is  a  need  to  query  the  capabilities  of  a  terminal.  In 
particular,  a  programmer  needs  to  be  dale  to  determine  which  of 
the  "terminal  I/O"  interfaces  are  efficiently  aqpported  and 
which  are  inefficiently  supported. 


SECTION  4:  SECURITY  DISCUSSION  GROUP 

The  mein  topics  addressed  by  the  discussion  group  on  security  wares 

a)  CAIS  dictation  of  security  policy 

b)  mandatory  versus  discretionary  security. 

Other  issues  were  discussed,  and  a  set  of  ratxnmai stations  was  made. 
These  reconmandations  appear  at  the  end  of  this  section. 

The  general  atmosphere  of  the  discussion  was  one  of  aoncem  over  the 
tight  coupling  of  security  policy  with  the  current  CMS  interfaces. 

.  Same  were  concerned  that  the  OVZS  dictates  a  certain  security 
policy,  as  wall  as  a  modal  for  iaqplawitlng  that  policy. 

It  wes  felt  that  there  are  several  problems  with  this  approach. 
The  OVISWG  has  used  the  DoD  Trusted  Ccnputer  System  Evaluation 
Criteria  as  the  besis  far  the  mandatary  and  discretionary 
security  aspects  found  in  CAIS  1.3.  This  guide  is  published  by 
the  Department  of  Defense  Ccnputer  Security  Center.  It 
proddes  "a  uniform  set  of  basic  requirements  and  evaluation 
classes  for  assessing  the  effectiveness  of  security  oontrols 
built  into  Automated  Data  Processing  (ADP)  systems."  This  guide 
itself  does  not  require  a  specific  policy;  it  only  establishes 
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criteria  for  the  achievement  of  various  levels  of  security. 
The  current  CAIS  approach  that  dictates  a  certain  security 
policy  mkas  it  difficult  or  impossible  to  implement  the  CMS 
an  tap  of  security  kernels  that  enfaody  different  policies  and 
um  different  mechanises .  It  was  felt  that  the  CMS  should 
define  a  simple  interface  to  a  security  mschanima,  rather  than 
the  amdmnism  itself  and  a  security  policy  implemented  by  the 


Even  if  this  approach  was  desirable,  it  would  not  be  wise  for 
the  CMS  to  simply  define  seme  new  security  mechanism. 
Security  mechanisms  require  thorou$i  analysis  to  determine 
their  validity,  and  the  CMS  should  not  be  tied  to  a  mechanism 
that  has  not  undargona  this  analysis.  Extensive  research  is 
still  being  invested  in  discovering  good  security  models.  The 
OHS  interface  should  therefore  allcw  many  security  models  and 
should,  in  general,  be  flexible.  It  wee  pointed  out  that  the 
security  ocamunity  itself  does  not  have  standards  for  security 
policies  and  mechanisms,  so  the  CMS  probably  should  not  try  to 
define  one. 


It  wee  also  motioned  by  one  person  in  the  group  that  the 
approach  does  not  allow  for  Multics-style  ring  protection, 
althou^i  other  lUBShera  of  the  groqp  expressed  doubt  that  ring 
protection  pertained  to  Programming -Support  Envixtxsnant  tools. 

Group  opinion  wee  divided  as  to  what  should  happan  regarding 
this  question  far  (MS  Version  l.  Althou£i  it  was  generally 
agreed  that  the  security  amdianiams  rtould  be  asperated  at 
least  into  one  chapter,  possibly  into  an  appendix,  there  were 
two  views  as  to  whet  should  happan  for  CMS  Version  it 

a.  Raap  the  current  security  in  the  CMS  as  a  basis  for 
further  work  and  omwanjial  iaplanmntaticne;  make  Version 
2  a  secure  system,  but  change  Version  1  to  allow  different 
mechanism  also. 

b.  If  you  can’t  prove  that  it’s  secure,  leave  out  the  current 
security  mechanism;  dsfins  generic  interfaces  (What 
exceptions  will  bs  raised),  allow  for  lack  of  visibility 
(see  next  topic)  and  possibly  leeve  security  mechanimne  in 
an  appendix. 


2*  Should  the  CMS  security  policy  and  mechanisms  be  visible  to 
the  user  or  tods? 

It  ms  felt  that  tha  CMS  should  allow  the  implementation  to 
choose  to  make  seme  nodes  not  'visible'  to  acme  subject  (the 
CMS  already  allows  this)  and  that  it  should  let  the 
inplaraantation  provide  a  policy  for  governing  vhan  this  happens 
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and  a  machaniam  for  doing  it*  Soaa  also  fait  it  is  not 
naoassazy  to  have  the  security  information  visible  to  the  user 
(i.e«,  classification  lahals  in  AIS  1.3  are  node  attributes). 
It  vns  notsd  that  a  tool  writer  and  user  should  not  have  to 
worry  about  the  security  policy  and  mechanism;  it  should  be 
transparent  to  the  tool/ user.  However,  opinion  was  divided,  as 
sans  felt  that  separating  out  security  mechanism  from  the  CMS 
is  not  in  support  of  portability,  while  some  felt  that  portable 
programs  should  not  rely  on  a  specific  security  policy  or 


Some  felt  that  the  CMS  should  treat  DoD  security  (mandatary 
security)  separately  from  oaanercial  security  (discretionary 
security).  Most  of  the  discussion  centered  around  mandatory 
security.  Sams  felt  that  discretionary  aooaaa  control  should 
be  left  in  the  CMS  because  it  is  useful. 


the  level  of 


As  noted  above,  sufficient  analysis  of  the  proposed  CAIS 
mechanism  has  not  bean  performed,  so  no  claims  about  the  level 
of  security  provided  are  warranted. 


felt  that 


ty  ixmnsilty  in 
ar  in  particular. 


mean  the 


the  DoD 


to  the  CMSM31. 


ty  the  group  to 


a.  The  security  policy  model  should  be  separated  from  the  CMS 


b.  the  CAIS  docunant  should  not  state  that  tha  CAIS  supplies  a 
"security  mechanism",  as  the  validity  of  such  a  system 
requires  thorough  analysis  and  proof.  Iha  term  "security 
systmn"  should  be  Ranged  to  "protective  controls". 

c.  Conditions  under  which  the  exceptions  Access  violation. 
Security  Violation,  and  Name_Errcr  are  raised  "should  be 
apart  fisiT  as  reconmandationa;  final  specification  should 
be  left  to  the  inplsmantor  of  the  tyetam. 


d.  in  order  to  isolate  security  mechanisms  in  the  (AIS, 
security  information  should  be  stored  as  attributes  with 

functionality  (not  accessible  by  users). 

e.  The  CMS  should  allow  different  security  policies;  it 
should  not  mandate  a  specific  one. 

f .  An  implementor  of  the  security  kernel  should  be  required  to 
specify  functionality  and  use  of  the  kernel  and  to  specify 
the  exceptions  that  are  raised  at  the  GAIS  interface  and 
under  vhat  conditions  they  are  raised. 


SECTION  5:  NON-TECHNIC AL  ISSUES  DISCUSSION  GROUP 

The  main  topics  addressed  by  the  discussion  group  on  nan-technical 

issues  weres 

a)  the  push  for  a  military  standard  (MXL-SED)  in  January  1965 

b)  the  need  to  establish  a  standard  at  all 

c)  the  expected  ooet/benefit  of  such  a  standard. 


Hie  general  atmosphere  of  the  discussion  was  that  such  a  aomni  set  of 
interface*  would  be  desirable,  but  that  more  time  is  required  to 
properly  address  all  of  the  issues  involved. 

1.  the  OIS  is  ledjil.luim  with  respsrt  to  the  current  state  of  the 
art.  and  it  is  oosplex. 

This  statement  was  being  quoted  from  one  of  the  KTTIA  members. 
Afternoon  contributors  who  had  bean  in  other  groups  in  the 
morning  reported  that  the  node  model  groip  had  not  considered 
the  node  model  to  be  pushing  the  state  of  the  art,  and  the 
process  group  said  that  parts  of  the  CAIS  were  not  yet  qp  to 
the  state  of  the  art.  It  was  suggested  that  this  wes  a 
reaction  based  on  the  Ada  experience  in  which  the  aspects  of 
each  conpcnant  are  known,  but  unexpected  amplications  arise 
whan  all  thsse  are  put  together.  It  wes  acknowledged  that  the 
inpact  of  the  security  mechanises  is  lass  well-known. 


2.  There  is  insufficient  calendar  tins  for  public  review  between 
now  and  Jbnusry  1965. 

It  was  felt  that  viable  public  reviews  could  not  be  adiieved  if 
the  CAIS  was  to  be  made  a  MIL-STO  so  quickly. 


3-14 


3.  Am  is  insufficient  tia  to  proto  a  croUbLi  docusnt. 

The  shear  effort  required  to  take  oece  of  all  the  missing 
details  and  to  correct  all  typos  and  other  minor  errors  was 
felt  to  be  too  great  for  the  tine  available  between  now  and 
January. 


B 


m 

to 


4. 


is  no  technical 


with 
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It  appears  that  the  CMS  is  a  "solution"  document,  but  the 
technical  requirmnants  docmsnt  to  whidn  this  interface  set  is 
responding  is  missing.  It  was  pointed  out  that  the  interface 
set  now  called  the  CMS  had  evolved  from  a  study  of  the  ASS  and 
ALS  and  that  it  took  its  requirmaants  largely  from  agremnant. 
betwean  thoee  two  systems  about  what  a  "KAPSE"  was.  both  in 
level  and  content.  A  requirmnants  documant  is  being  generated 
now  Which  will  guide  the  development  of  CMS  Version  2,  and  its 
development,  although  in  parallel  with  the  production  of  CMS 
Version  1,  has  had  acne  inpact  already. 


I 
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5.  tty  is  the  OUS  being  made  a  MH/-SID 7  Mist  dose  the  DoD  aspect 
to  aoaopliab  by  amirlnj  it  one? 

Host  of  the  group  discussion  wee  spent  on  this  set  of  concerns. 
Ihe  discussions  cantered  around  a  few  main  issues. 


a.  A  ms  would  ba  good  in  the  long  runt  TWo  votes  were  taken 

in  the  morning  session.  In  them  votes,  e  clear  majority 
(about  30  to  5)  felt  that  the  CMS  (i.e.,  same  set  of 
conwon  interfaces  at  about  this  level)  would  be.  useful  in 
the  long  run  and  of  benefit  to  the  whole  oanmxnity. 
However,  the  vote  was  unanimous  that  January  1905  was  too 
early  for  a  military  standard;  the  vote  was  on  the 

question  "is  a  KZL-0TD  in  January  1905  premature?" 

b.  This  approach  does  not  maah  well  with  the  current 

ocesmcc  ini  marketplaces  It  seame  that  there  is  not  a  lot 
of  industry  impetus  right  now  for  Sharing  tools.  Most 
contractors  currently  have  one  or  more  host  eystams 
in  house  which  they  urn  for  development  end  maintenance  of 
the  system  they  produce.  The  requirmnent  to  conform  to 
the  CMS  would  mean  a  considerable  delay  and  expense  for 
everyone;  it  is  easier  to  transport  or  even  re- implement 
one  tool  than  it  is  to  re-do  one's  thole 

tool-suite/host-system  to  conform  to  the  GAIS. 

The  primary  service  ocnoara  is  for  simplifying  life-cycle 
sqpport.  It  was  suggested  that  the  services  should  accept 
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a  demonstration  of  a  system's  maintainability  in  a  aarvioa 
environment,  rathar  than  insist  an  uss  of  a  particular  sat 
of  tools.  It  is  arguad  that,  especially  in  the  short  term, 
it  will  be  acre  cost-effective  to  use  what  everyone  already 
has  in-house  than  to  Impose  a  new  set  of  interfaces. 

c.  Mo  cost/banefit  analysis  exists  to  sqpport  the  DoD's 
perspective  on  potential  payoff  from  this  approach!  The 
DQD  has  based  touch  of  the  Ada  pcograa  on  the  philosophy 
that  the  more  that  is  canon,  the  more  will  be  shared  and 
the  more  we  will  be  able  to  cut  costs.  But  we  currently 
have  no  real  answers  to  such  questions  as  what  it  will  cost 
to  build  a  CMS  implementation  or  what  it  will  take  to 
effectively  move  tools  between  QMS  implementations. 

The  real  question  was  whether  or  not  the  expected  payoff 
wee  there.  The  suggestion  wes  made  that  the  DoD  needs  to 
do  e  ooet  analysis  of  the  expense  of  implementing  the  CMS 
versus  the  sipanse  of  writing  all  the  intended  tools  in  Ada 
for  all  the  different  operating  systems  currently  in  uss 
for  such  work.  It  was  suggested  that  this  analysis  dhould 
separate  out  the  concept  of  writing  tools  in  Ada  from  the 
further  complication  of  writing  them  in  Ada  for  the  CMS, 
since  Ma  itself  is  supposed  to  be  transportable.  The 
analysis  should  also  include  the  cost  of  running  the  tools 
an  a  CMS  implementation  which  is  piggy-backed  on  another 
operating  system.  Another  aspect  to  be  considered  is  the 
effect  that  the  CMS  might  have  on  how  new  tools  are 
approached  and  written. 

It  must  be  kept  in  mind,  however,  that  the  expected 
benefits  of  the  CMS  amessd  the  vision  of  a  single 
contractor;  they  must  be  "amortised"  over  many  projects 
conducted  by  many  contractors  for  the  DoD  as  a  whole. 

d.  The  means  of  transitioning  to  the  GA1S  is  a  key  element  in 
its  success!  The  key  point  in  this  discussion  was  that, 
just  as  with  the  language,  there  must  be  a  transition  plan 
for  the  CMS.  This  plan  xust  handle  the  near  term  problem 
of  starting  to  gat  the  CMS  in  use  While  not  requiring  that 
existing  oaapleta,  integrated  environments  be  overhauled  to 
include  the  CAIS.  It  wes  noted  that  we  do  not  want  to  lose 
the  opportunity  to  capture  scam  new  projects  Which  are  just 
now  putting  nsw  development  environments  together,  but  we 
do  not  went  to  disnpt  work  that  is  currently  being  done 
successfully  in  existing  environments.  That  is,  the  CAIS 
should  be  applied  to  nsw  projects,  and  existing  projects 
should  not  be  expected  to  retrofit  their  existing 
facilities. 

s.  The  real  fear  about  making  the  CAIS  a  standard  is  that  it 
will  ba  recklessly  or  inappropriately  applied:  Given  the 
vote  in  favor  of  a  common  set  of  interfaces  but  the 


sentiment  against  a  near-term  MIL-STO,  the  question  was 
asked  "If  not  a  MIL-STO,  than  what?  Would  it  be  better  as 
an  IEEE  or  ANSI  standard,  for  exanple?"  The  consensus  was 
that  the  declaration  of  AN*  standard  -  not  just  a  military 
one  -  at  this  point  would  cause  everyone  great  aoncem. 
The  conoam  focuses  on  the  expectation  that  a  military 
standard  (or  any  standard,  for  that  matter)  would  have  an 
aura  of  authority  that  would  lead  people  to  misapply  it  to 
contract  situations  where  it  is  not  appropriate. 


The  conclusion  was  that  the  policy  used  in  applying  this 
standard  must  be  perceptive  enough  to  apply  it  discrixninately. 
Particularly  in  the  first  year  or  two,  it  would  be  much  more 
appropriately  applied  to  contracts  for  prototypes  of  tools  and 
OVIS  implementations  than  to  ary  contract  for  an  applications 
system  in  Which  the  delivery  of  tools  is  more  or  less 
incidental.  A  lot  of  these  concerns  might  be  alleviated  if  the 
issuance  of  the  CMS  standard  were  accompanied  by  guidelines 
for  its  imposition  on  contracts. 


Bam  dose  the  CMS  relate  to  a  "standard  DcD  operating  ayata"? 

This  question  was  not  dismissed  much.  It  was  pointed  out  that 
the  CAES  wee  being  developed  in  response  to  a  tri-service 
memorandum  of  agreement  calling  for  a  set  of  interfaces  to 
support  the  sharing  of  tools.  Any  reseda!  ancs  it  may  bear  to  a 
"standard  DaD  operating  system”  is  just  the  result  of  the  foct 
that  the  interfaces  required  to  support  transportability  tend 
to  look  a  lot  like  a  virtual  operating  system.  There  is  no 
known  charter  currently  to  develop  a  standard  DcD  operating 
system  nor  any  known  interest  in  establishing  such  a  charter. 


Whet  are  the  real  proepects  for  achieving  CMS  validation? 

The  prospect  of  CMS  validation  appeared  frightening  to  several 
discussants  for  two  main  reasons  i  (1)  the  perceived  acnjplexity 
of  the  CMS  and  (2)  the  perceived  lade  of  technology  to  define 
the  tests  and  experiments  to  achieve  it.  The  basic  consensus 
wee  that  we  do  not  know  enough  yet.  During  the  conversation  it 
became  apparent  that  people  were  variously  talking  about  one  or 
more  of  at  lsast  three  things  vhen  they  spoke  of  "CMS 
validation"  t 

-  validating  that  an  implementation  meats  the  specification 
(this  is  vhat  the  M T,  KOTA  and  E&V  teams  mean  by  "CMS 
validation") 


-  "validating"  the  CMS  concepts,  i.e.,  prototyping 


-  "validating"  that  two  raal  CMS  implementations  really 
achieve  transportability;  i.e.,  showing  that  the  fact  that 
two  implementations  conform  to  the  CMS  means  that  they 
easily  can  share  tools. 


should  be 


of  the  distrlbutivity  of  the 


The  general  question  was  when  and  how  mould  this  and  other 
deferred  issues  in  the  current  CMS  be  addressed. 
Dietributivity  wee  juet  one  example.  In  particular,  it  weue 
stated  by  one  participant  that  the  transparency  to  distribution 
which  wee  pursued  for  CMS  Version  1  would  not  be  adequate  and 
that  explicit  aontzol  over  such  aspects  would  be  required. 
These  will  all  be  topics  for  the  Version  2  contractor. 


to  the  CMS 


Hnn  uf  expressed  over  what  wee  the 

"monolithicness"  of  the  CMS;  i.e.,  the  words  concerning 
aonfomenoe  in  the  current  draft  imply  that  an  inplamantation 
must  have  all  the  interfaces  exactly  as  Aown,  with  a  few  minor 
exceptions  in  detail.  It  is  recognised  that  it  is  not 
practical  to  require  absolutely  every  package  of  absolutely 
every  impimnmxtation,  yet  it  is  desirable  for  all  things 
calling  thsmeelves  "CMS  implementations”  to  have  a  substantial 
umber  of  interfaces  in  acxnon. 
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This  1%  >  i  —H  has  bean  pnpand  in  response  to  the  Memorandum  of 
Hyiaanr  signed  by  tha  Undersecretary  of  Defense  and  tha  Aasistant 
Sacratariaa  of  the  Air  Porae,  Any,  and  Navy.  Tha  memorandum 
established  agreasmnt  for  defining  a  aat  at  aoaaon  interfaces  for  the 
rafi taut  of  Dafanaa  (DoD)  Ada  Piugremaiiej  St^pxt  Brvircnmanta  (APSEs) 
to  promts  Ada  tool  transportability  and  interoperability.  Tha  initial 
intarfaoaa  for  tha  CAXS  ware  derived  from  tha  Ada  Integrated  Environment 
(AXE)  and  the  Ada  language  Systaai  (Aid).  Since  than  tha  GAIS  has  been 
axpandad  to  be  iapl—ntabla  aa  part  of  a  wide  wristy  of  APSEs.  It  is 
anticipated  that  the  GAXS  will  evolve,  changing  to  mast  new  needs. 
Thxougpi  the  acceptance  of  this  standard,  it  is  anticipated  that  the 
source  level  portability  of  Ada  software  tools  will  be  enhanced  far  both 
DoD  and  non-OoD  users. 

The  authors  of  this  document  include  technical  representatives  from  the 
two  DoD  APSE  contractors,  representatives  from  the  DoD's  Kernel  Ada 
Programing  Support  Bwircrmant  (KAPSE)  Interface  Team  (KIT),  and 
volunteer  representatives  fraa  tha  KAPSE  Interface  Team  from  Industry 
and  Academia  (KTTIA) . 

The  initial  effort  for  definition  of  the  CAIS  wee  begun  in  Septentoer 
1982  by  the  following  mentoata  of  the  KAPSE  Interface  Team  (KIT):  J. 
Foidl  (TRW),  J.  Kramer  (Institute  for  Defense  Analysis),  P.  Obemdorf 
(Naval  Ocean  Systmns  Center),  T.  Taft  (Intsnnatrics),  R.  Thall 
(SofTsdi)  and  W.  Wilder  (NAVSEA  PM6-408).  In  February  1983  the  design 
team  mbs  expanded  to  include  LCDR.  B.  Schaar  (Ada  Joint  Program 
Office)  and  KAPSE  Interface  Team  fraa  Industry  and  Academia  (KTITA) 
mantoers:  H.  Fischer  (Litton  Data  Systems),  T.  Harrison  (Texas 
Instruments),  E.  Lento  (Ball  Labs),  T.  Lyons  (Software  Sciences  Ltd., 
U.K.),  D.  MoQonagle  (General  Electric),  H.  Morse  (Fray  Federal 
Systems),  E.  Ploedereder  (Tartan  Laboratories),  H.  Willraan  (Raytheon), 
and  L.  Yelowitz  (Ford  Aerospace) .  During  1984,  the  following  people 
assisted  in  preparation  of  this  document:  K.  Connolly  (TRW),  S. 
Fentan  (Data  General),  G.  Fitch  (Intermetrics),  R.  Gouw  (TRW),  B. 
Grant  (Intermetrics),  N.  Lae  (IDA),  J.  Long  (TRW),  and  R.  Robinson 
(IDA).  Additional  constructive  criticism  and  direction  warn  provided  by 
G.  Myers  (Naval  Ocean  Systems  Center),  R.  Olivier  ( Inform tiquxe 
Internationale),  and  the  general  memberships  of  the  KIT  and  KXTIA,  as 
well  as  many  independent  reviewers.  (The  Ada  Joint  Program  Office  is 
particularly  grateful  to  those  KTITA  members  and  their  ocnpanies  for 
providing  the  time  and  resources  that  significantly  contributed  to  this 
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1.  SCOPE 


1.1  Purpose 


This  document  provides  specifications  for  a  set  of  Ada  packages,  with 
their  intsndsd  semantics,  vhidi  together  form  the  set  of  cannon 
interfaces  for  Ada  Programing  Support  Environments  (APSEs).  This  set 
of  interfaces  is  known  as  the  GoasDn  APSE  Interface  Set  (GAIS).  This 
interface  set  is  designed  to  pcanote  the  source-level  portability  of  Ada 
programs,  particularly  Ada  software  development  tools.  This  version  of 
the  CAIS  is  intended  to  provide  the  basis  for  evolution  of  the  CMS  as 
APSEs  are  inplanamted,  as  tools  are  transported,  and  as  tool 
interoperability  issues  are  encountered.  Tools  written  in  Ada,  using 
only  the  packages  described  herein,  should  be  transportable  between  CAIS 
inplemantaticns.  Where  tools  function  as  a  set,  the  CAIS  facilitates 
transportability  of  the  tool  set  as  a  Whole;  tools  might  not  be 
individually  transportable  because  they  depend  an  inputs  from  other 
tools  in  the  set. 

The  CAIS  applies  to  Ada  Programing  Support  Environmnts  ,  which  are  to 
become  the  basic  software  life-cycle  environments  for  DoD 
Mission-Critical  Oonputsr  Systems  (KXS) .  Those  Ada  programs  that  are 
used  in  support  of  software  development  are  defined  as  "tools”.  This 
includes  the  spectrin  of  support  software  from  project  management 
through  code  development,  configuration  management  and  life-cycle 
support.  Tools  are  not  restricted  to  only  those  software  items  normally 
associated  with  program  generation  such  as  editors,  compilers, 
debuggers,  and  linker-loaders.  Groups  of  tools  that  are  oonposed  of  a 
number  of  independent  but  inter-related  programs  (such  as  a  debugger 
which  is  related  to  a  specific  aaapiler)  are  classed  as  "tool  sets"  Cl]. 

Since  the  goal  of  the  CAIS  is  to  promote  interoperability  and 
transportability  of  Ad a  software  across  DoD  APSEs,  the  following 
definitions  of  these  terms  are  provided.  "Interoperability"  is  defined 
as  "the  ability  of  APSEs  to  exchange  data  bass  objects  mid  their 
relationships  in  forms  usable  by  tools  and  user  programs  without 
conversion."  "Transportability"  of  an  APSE  tool  is  defined  as  "the 
ability  of  the  tool  to  be  installed  on  a  different  KAPSE;  the  tool  must 
perform  with  the  same  functionality  in  both  APSEs.  Transportability  is 
measured  in  the  degree  to  which  this  installation  can  be  acocnplished 
without  reprogramming.  Portability  and  transferability  are  carnally 
used  synonyms."  [2] 


Cl]  Requirements  for  Ada  Programming  Support  Environments,  "Storeman"; 
of  Defense;  February  1960. 

Interface  Team:  Public  Report,  Volume  I,  1  April  1982;  p. 


PROPOSED  KXL-SID-CAIS 
31  OCT  1964 


1.2  Content 


this  version  of  the  CMS  establishes  interface  requirements  for  the 
transportability  of  Ada  tool  sets  to  be  utilised  in  Department  of 
Defense  (DoD)  APSEs.  Strict  adherence  to  this  interface  set  will  ensure 
that  the  Mb  tool  sets  will  possess  the  highest  degree  of  portability 
across  conforming  APSEs. 

The  scope  of  the  CMS  includes  interfaces  to  those  services 
traditionally  provided  by  an  operating  system  that  affect  tool 
transportability.  Ideally,  all  APSE  tools  would  be  iaplsnsntable  using 
only  the  Ma  language  and  the  CMS.  This  version  of  the  CMS  is 
intended  to  provide  the  transportability  interfaces  most  often  required 
by  ocuman  software  development  tools  and  includes  four  interface  arses* 


a.  Node  Model.  This  area  presents  a  model  far  the  CMS  in  which 
contents,  relationships  and  attributes  of  nodes  are  defined.  Also 
included  are  the  foundations  for  access  control  and  access 
synchroni  ration. 

b.  Process  Nodes.  This  area  aovere  program  invocation  and 
control. 

c.  Irput/Oqput.  This  area  covers  file  input/output,  basic  device 
input/output  support,  special  device  control  facilities,  and 
interprocess  aonramication. 

d.  Utilities.  This  area  covers  list  operations  useful  for 
parameter  and  attribute  value  manipulation. 


1.3  Excluded  and  deferred  topics 


During  the  desist  of  this  version  of  the  CMS  it  wee  determined  that 
interfaces  for  environments  which  are  not  software  'development 
environments  (for  example,  interfaces  an  target  systems)  and  interfaces 
for  multi-lingual  anvironnanta  should  be  explicitly  excluded.  It  has 
bean  decided  that  backup  facilities  will  be  supported  transparently  by 
the  CMS  isplamantation.  While  the  interface  issues  of  most  aspects  of 
environments  were  considered,  the  complete  resolution  of  several  areas 
has  been  deferred  until  later  revisions  of  the  CMS. 

Configuration  nanagmmnt  -  The  current  (MS  supports 
facilities  for  configuration  control  including  keeping 
versions,  referencing  the  latest  revision,  identifying 
the  state  of  an  object,  etc.,  but  it  does  not 
itqplament  a  particular  methodology.  Currently 
deferred  is  the  decision  whether  or  not  to  have  the 
CMS  enforce  e  particular  configuration  management 
approach  and  if  ao  what  particular  methodology  tfwuld 
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Davies  control  and  resource  management  -  The  current 
CAIS  provides  acntzol  facilities  far  scroll,  page, 
and  form  terminals  and  magnetic  tape  drives.  Currently 
deferred  is  the  decision  as  to  what  additional  devices 
or  resources  trust  be  supported  by  the  CMS.  Such 
resources  and  devices  might  include  printers,  disk 
drives,  color  terminals,  vector-  and  bit-addressable 
graphics  devices,  processor  memory,  processor  time, 
acsnunication  paths,  etc.  Also  deferred  is  a  decision 
regarding  which  other  ANSI/I9D  interfaces  to  adept, 
such  as  the  ISO/DXS  7942  Graphical  Kernel  System  (GKS) . 

Distributed  environments  -  The  existing  CMS  packages 
are  intended  to  be  iiqplementable  on  a  distributed  set 
of  processors,  but  this  would  be  transparent  to  a 
tool.  Currently  deferred  is  the  decision  whether  or 
not  to  provide  to  the  user  explicit  CATS  interfaces  to 
control  the  distribution  of  the  environment,  including 
designation  of  there  nodes  exist  and  where  execution 
takes  place.  Note  that  a  set  of  distributed  processors 
could  include  one  or  mors  target  machines. 


Inter-tool  interfaces  -  The  current  CMS  does  not 
define  inter-tool  calling  sequences  or  data  formats 
such  as  the  data  format  within  the  oenpilat  ion/ program 
library  system,  the  text  format  within  editing 
systems,  the  contend  processor  language  syntax,  the 
message  formats  of  a  mail  system,  or  the  interaction 
between  the  rut-time  system  and  debugger  tools. 
Currently  deferred  are  decisions  regarding  that  inter- 
tool  data  should  baoome  part  of  the  standard,  vhat 
form  such  interfaces  should  take,  and  whether  or  not 
to  place  constraints  an  the  run-time  to  provide 
process  execution  information. 


Interoperability  -  [The  current  GIS  provides  only 
a  very  primitive,  text-oriented  interface  for 
transferring  files  between  a  CMS  inplemantation  and 
the  operating  system  on  vhich  it  may  reside.]  It  does 
not  define  external  representations  of  data  for 
transfer  bstwean  environments  or  between  host  and 
target. 

Typing  methodology  -  The  currant  CMS  provides 
attributes  and  relations  which  can  be  used  by  tool 
sets  to  oonstrain  nodes,  attributes  and  relations 
but,  it  does  not  enforce  a  particular  methodology. 
Currently  deferred  is  a  decision  whether  or  not  the 
CMS  should  enforce  a  particular,  more  ocnplete  typing 
methodology  and  what  kind  of  CMS  interfaces  should  be 
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mad*  available  to  sqpport  it. 

Archiving  -  Thi  currant  GAIS  does  not  define 
facilities  for  archiving  of  data.  Currently  deferred 
ia  a  deciaicn  regarding  the  fora  that  archiving 
interfaces  should  take. 


PROPOSED  MXL-STO-CAIS 
31  OCT  1964 


I 
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2. 


Issues  of  docunsnta 


RffQQCS  DOOmBffiS 


Ths  following  docunsnts  of  the  issue  in  effect  on  date  of  invitation  for 
bids  or  request  for  proposal  form  a  part  of  this  standard  to  the  extent 
specified  herein. 

CUM]:  Reference  Manual  for  the  Ada  Programming  Language, 
ANSI/MTL-STD-1815A;  United  States  Department  of  Defense;  January  1963. 

CSPGNBAN]:  Requirements  for  Ada  Programming  Support  Environments, 
"Storeman";  Department  of  Defense;  February  1960. 

(Copies  of  specifications,  standards,  drawings,  and  publications 
required  by  contractors  in  connection  with  specific  procurement 
functions  should  be  obtained  from  the  procuring  activity  or  as  directed 
by  the  contracting  officer.) 


2.2  Other  publications 


The  following  documents  form  a  part  of  the  standard  to  the  extent 
specified  herein.  Unless  otherwise  indicated,  the  issue  in  effect  an 
date  of  invitation  for  bids  or  request  for  proposal  shall  apply. 

[ANSI  78]  i  American  National  Standards  Institue,  "Magnetic  Tape  Labels 
and  File  Structure  for  Information  Interchange  (ANSI  Standard 
x3. 27-1978)";  (Application  for  copies  should  be  addressed  to  American 
National  Standards  Institute,  Inc.,  1430  Broadway,  New  York,  NY  10018) 

[DACS]  -  DACS  glossary,  a  Bibliography  of  Software  Engineering  Terms, 
GL06-1,  October  1979,  Data  and  Analysis  Center  for  Software. 

COB]  -  UBS  Standard  Glossary  of  Software  Engineering  Terminology, 
ANSI/IEEE  Std  729-1963. 

[TCSEC]  -  Department  of  Defense  Trusted  Ocnputer  System  Evaluation 
Criteria,  Department  of  Defense  Computer  Security  Center, 
CSC-0XD-001-63,  15  August  1963. 

[UK  Ada  Study]  -  United  Kingdom  Ada  Study  Final  Technical  Report,  Volune 
I,  London,  Department  of  Industry,  1981. 
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3.  EEFINITICNS 


The  following  are  terms  which  are  used  in  the  description  of  the  CATS. 
Words  followed  by  *  are  defined  by  the  CMS  docunent  in  terns  of  the 
CMS  desi^i.  Where  a  docanent  named  in  Section  2  was  used  to  obtain  the 
definition,  the  definition  is  preceded  by  a  bracketed  reference  to  that 
document. 

abort  -  [IEEE]  To  terminate  a  process  prior  to  ccnpletion. 

access  -  [TCSEC]  A  specific  type  of  interaction  between  a  subject  and  an 
object  that  results  in  the  flow  of  information  from  one  to  the  other. 

access  checking  -  The  operation  of  checking  access  rights  with  intents 
according  to  the  access  control  rules  and  either  permitting  or  denying 
the  intended  operation. 

access  control  -[TCSEC  -  discretionary  access  control]  A  means  of 
restricting  access  to  objects  based  on  the  identity  of  subjects  and/or 
groups  to  which  they  belong.  The  controls  are  discretionary  in  the 
sense  that  a  subject  with  a  certain  access  permission  is  capable  of 
passing  that  permission  (perhaps  indirectly)  on  to  any  other  subject. 
[TCSEC  -  mandatory  access  control]  A  means  of  restricting  access  to 
objects  based  cn  the  sensitivity  (as  represented  by  a  label)  of  the 
information  contained  in  the  Objects  and  the  formal  authorization  (i.e. 
clearance)  of  subjects  to  access  information  of  such  sensitivity.  In 
the  CMS,  this  includes  specification  of  access  rights,  access  control 
rules  and  checking  of  access  rights  in  accordance  with  these  rules. 

access  control  constraints  -  All  the  information  required  to  perform 
access  checking. 

access  control  information  -  The  resulting  restrictions  placed  an 
certain  kinds  of  operations  by  access  control. 

access  control  rules  -  The  rules  describing  the  correlations  between 
access  rights  and  intents. 

access  rights  -  Descriptions  of  the  type  of  operations  which  can  be 
performed  (See  Section  4. 4. 1.2). 

accessible  *  -  The  subject  has  (.adapted  a  role  which  has)  been  granted 
access  right  EXISTENCE  to  the  object. 

active  position  -  The  position  at  vhich  a  (terminal)  operation  is  to  be 
performed. 

Ada  Progr awning  Support  Environment  (APSE)  -  [UK  Ada  Study,  STCNEMAN]  A 
set  of  hardware  and  software  facilities  whose  purpose  is  to  support  the 
development  and  imintenance  of  Ada  applications  software  throughout  its 
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life  cycle,  with  particular  emphasis  on  software  for  embedded  ccnputer 
applications .  The  principal  features  are  the  database,  the  interfaces 
and  the  toolset. 

adopt  a  role  *  -  The  action  of  a  process  to  acquire  the  access  rights 
which  have  been  or  will  be  granted  by  an  object  to  adopters  of  that 
role;  in  the  (MS  this  is  accomplished  by  establishing  a  secondary 
ADOPTT35_RQLE  relationship  from  the  process  node  to  the  role. 

adopted  role  of  a  process  *  -  The  role  or  ancestor  of  the  role  that  is 
the  target  of  an  ADOPTED_ROLE  relationship  frcm  the  process  node. 

advance  (of  an  active  poetion)  -  Takes  place  an  a  scroll  or  page 
terminal  whenever  (1)  the  row  nurtber  of  a  new  position  is  greater  than 
the  row  lumber  of  the  old  or,  (2)  the  row  number  of  the  new  position  is 
the  same  but  the  aoltsm  number  of  the  new  postion  is  greater  than  that 
of  the  old;  takes  place  cn  a  form  terminal  whenever  the  indices  of  its 
position  are  incremented. 

ancestor  of  a  role  *  -  Any  group  reachable  from  the  given  role  via 
PARENT  relationships. 

area  qualifier  -  A  designator  for  the  beginning  of  a  qualified  area. 

associate  -  TO  establish  a  correlation  between  a  queue  file  and  a 
secondary  storage  file.  If  the  file  is  a  copy  queue  file,  its  initial 
contents  are  a  copy  of  the  associated  file;  if  the  queue  file  is  a 
mimic  queue  file,  its  initial  contents  are  a  copy  of  the  associated  file 
and  elements  that  are  written  to  the  mimic  queue  file  are  appended  to 
its  associated  file. 

attribute  *  -  A  named  value  associated  with  a  node  or  relationship  which 
provides  information  about  that  node  or  relationship. 

base  *  -  The  given  starting  node  of  a  path. 

contents  *  -  A  file  or  process  associated  with  a  CAIS  node. 

current  node  *  -  The  node  that  is  currently  the  focus  or  context  for  the 
activities  of  the  current  process. 

current  process  *  -  The  currently  executing  process  making  the  call  to  a 
CAIS  operation.  It  defines  the  context  in  which  the  parameters  of  the 
call  are  to  be  interpreted. 

current  user  *  -  The  user's  top-level  node. 

dependent  process  node  *  -  A  process  node  which  is  not  a  root  process 
node. 

descendant  of  a  group  *  -  Ary  role  reachable  from  the  given  group  via 
primary  PERMANENT J*1EMBER  relationships. 


7 


3-35 


PROPOSED  MUr-OTD-CAIS 
31  OCT  1964 


device  -  A  piece  of  equipment  or  a  mechanism  designed  to  serve  a  special 
purpose  or  perform  a  special  function. 

device  name  *  -  The  key  of  a  primary  DEVICE  relationship  emanating  from 
the  system  node. 

file  -  CUM  14.1.1  -  Ada  external  file]  values  input  from  the  external 
environment  of  the  program*  or  output  to  the  environment,  are  considered 
to  occupy  external  files.  An  external  file  can  be  anything  external  to 
the  program  that  can  produce  a  value  to  be  read  or  receive  a  value  to  be 
written. 

file  node  *  -  A  node  those  contents  are  an  Ada  external  file,  e.g.,  a 
host  system  file,  a  device,  or  a  queue. 

group  *,  group  node  *  -  A  collection  of  roles  represented  by  a 
structural  node  with  emanating  relationships  identifying  each  of  the 
group's  mothers.  A  group  member  may  be  a  user  top-level  node,  a  program 
node,  or  another  group. 

identification  -  A  reference  to  a  node  provided  by  a  pathname  or  a 
base/key/relation  name. 

illegal  -  A  node  identification  in  vhich  the  pathname  or  the 
relationship  key  or  relation  name  are  syntactically  illegal  with  respect 
to  the  syntax  defined  in  Table  III. 

inaccessible  *  -  Hie  subject  has  not  (adopted  a  role  which  has)  been 
granted  the  access  right  of  EXISTENCE  to  the  object. 

initiate  *  -  To  place  a  program  into  execution;  in  the  C3VIS,  this  means 
a  process  node  is  created,  required  resources  are  allocated,  and 
execution  is  started. 

initiated  process  *  -  The  process  whose  program  is  placed  into 
execution. 

initiating  process  *  -  Hie  process  placing  a  program  into  execution, 
interface  -  [DADS]  A  shared  boundary. 

iterator  *  -  A  variable  vhidi  facilitates  iteration  over  nodes  (a  node 
iterator)  or  attributes  (an  attribute  iterator). 

job  *  -  A  process  node  tree,  spanned  by  primary  relationships,  which 
develops  under  a  root  process  node  as  other  (dependent)  processes  are 
initiated  for  the  user. 

key  *  -  See  relationship  key.  Hie  key  of  a  node  is  the  relationship  key 
of  the  last  element  of  the  node's  pathname. 

list  -  [IEEE]  An  ordered  set  of  items  of  data;  in  the  CAIS,  ah  entity 
of  type  LISTJTYFE  whose  value  is  a  linearly  ordered  set  of  data  items. 
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list  item  *  -  A  data  item  in  a  list. 

latest  key  *  -  The  final  part  of  a  key  that  is  automatically  assigned 
lexicographically  following  all  previous  keys  for  the  same  relation  and 
initial  relationship  key  character  sequence. 

named  *  -  A  list  item  which  has  a  name  associated  with  it  or  a  list  all 
of  whose  items  are  named. 

node  *  -  Representation  within  the  CATS  of  an  entity  relevant  to  the 
APSE. 


node  handle  *  -  A  value  that  represents  a  reference  (to  a  GAIS  node) 
that  is  internal  to  a  process. 

non-existing  node  -  A  node  vhich  has  never  been  created. 

object  -  [TCSBC]  A  passive  entity  that  contains  or  receives  information. 
In  the  CMS,  any  node  may  be  an  abject. 

open  node  handle  *  -  A  node  handle  that  has  been  assigned  to  a 
particular  node  by  means  of  an  OPEN  procedure. 

parent  *  -  The  source  node  of  a  primary  relationship. 

path  *  -  A  sequence  of  relationships  connecting  one  node  to  another. 
Starting  from  a  given  node,  a  path  is  followed  by  traversing  a  sequence 
of  relationships  until  the  desired  node  is  reached. 

path  element  *  -  A  portion  of  a  pathname  representing  the  traversal  of  a 
single  relationship;  a  single  relation  name/relationship  key  pair. 

pathname  *  -  A  name  for  a  path  consisting  of  the  concatenation  of  the 
names  of  the  traversed  relationships  in  the  path  in  the  same  order  in 
which  they  are  encountered. 

permanent  amber  *  -  A  group  amber  vhich  is  related  to  the  group  via  a 
primary  PEFMANEHT_MEMBER  relationship. 

position  -  A  place  in  an  output  device  in  vhich  a  single,  printable 
ASCII  character  may  be  graphically  displayed. 

potential  amber  *  -  A  group  amber  that  may  dynamically  acquire 
menbership  in  the  grop;  represented  by  a  role  that  is  the  target  of  a 
PCTEOTIAL_MEMBER  relationship  emanating  from  that  group  or  frcm  any  of 
that  group's  descendants. 

pragnatics  -  [  -  implementation  pracpmtics]  Constraints  imposed  by  an 
iopleroentation  or  use  that  are  not  defined  by  the  syntax  or  semantics  of 
the  CMS. 

primary  relationship  *  -  The  initial  relationship  established  from  an 
existing  node  to  a  newly  created  node  during  its  creation.  The 
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existence  of  a  node  is  controlled  by  the  existence  of  the  prinary 
relationship  of  vtfiich  it  is  the  target. 

privilege  specification  -  a  list  of  access  rights  in  accordance  with  the 
syntax  given  in  Table  III.  ^ 

process  *  -  The  execution  of  an  Ada  program,  including  all  its  tasks. 

process  node  *  -  A  node  vhoee  contents  represent  a  CMS  process. 

program  -  [LRM]  A  program  is  ocnposed  of  a  lumber  of  oonpilation  units, 
one  of  which  is  a  subprogram  called  the  main  program,  vrtiich  may  invoke 
subprograms  declared  in  the  other  ocnpilaticn  units  of  the  program. 

program  node  *  -  A  short-hand  reference  of  the  file  node  representing 
the  file  which  contains  the  executable  image  of  a  program. 

qualified  area  -  A  contiguous  group  of  positions  that  share  a  common  set 
of  characteristics. 

queue  -  [IEEE]  A  list  that  is  accessed  in  a  first-in,  first-out  manner. 

relation  *  -  A  class  of  relationships  sharing  the  same  name. 

relation  name  *  -  The  string  that  identifies  a  relation. 

relationship  *  -  In  the  node  model,  an  edge  of  the  directed  graph,  which 
emanates  from  a  source  node  and  terminates  at  a  target  node.  A 
relationship  is  an  instance  of  a  relation. 

relationship  key  *  -  The  string  that  distinguishes  a  relationship  from 
other  relationships  having  the  same  relation  name  and  emanating  from  the 
same  node. 

role  *  -  A  user  top-level  node,  program  node,  or  group  node  that  is  the 
target  of  a  secondary  RCLE  relationship. 

root  process  node  *  -  The  initial  node  created  vhen  a  user  enters  an 
APSE  or  when  a  new  job  is  created  via  the  CREATE_JCB  interface. 

secondary  relationship  *  -  An  arbitrary  connection  which  is  established 
between  two  existing  nodes. 

security  level  -  [TCSEC]  The  combination  of  a  hierarchical 
classification  and  a  set  of  ncn-hierarchical  categories  that  represents 
the  sensitivity  of  information. 

source  node  *  -  The  node  from  which  a  relationship  emanates. 

structural  node  *  -  A  node  without  oontents.  Structural  nodes  are  used 
strictly  as  holders  of  relationships  and  attributes. 
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subject  -  [TGSBC]  An  active  entity,  generally  in  the  form  of  a  person, 
process,  or  device  that  causes  information  to  flow  among  objects  or 
changes  the  system  stats.  In  the  GAIS,  a  subject  is  always  a  process 
nods.* 

system  node  *  -  The  root  of  the  entire  CAIS  node  structure. 

target  node  *  -  Node  at  vdiich  a  relationship  terminates. 

task  -  CUM]  An  entity  vhose  execution  proceeds  in  parallel  with  other 
parts  of  the  program. 

termination  of  a  process  *  -  Termination  ([I1M]  9.4)  of  the  subprogram 
Which  is  the  main  program  {[LEM]  10.1)  of  the  process. 

tool  -  [tree  -  software  tool]  A  ocnputar  program  used  to  help  develop, 
test,  analyze,  or  maintain  another  oonputer  program  or  its 
docimmntation;  for  exanple,  an  automated  design  tool,  oonpiler,  test 
tool,  or  maintenance  tool. 

top-level  node  *  -  The  root  of  the  tree  that  includes  all  of  the 
structural,  file  and  process  nodes  created  an  the  user's  behalf;  from 
it  the  user  can  access  these  and  others.  Each  user  has  a  top-level 
node. 

track  *  -  Open  node  handles  are  said  to  track  the  nodes  to  Which  they 
refer.  This  means  that  an  open  node  handle  is  guaranteed  always  to 
refer  to  the  same  node,  regardless  of  any  changes  to  relationships  that 
could  cause  pathnames  to  become  invalid  or  to  refer  to  different  nodes. 

traversal  of  a  node  *  -  Traversal  of  a  relationship  emanating  from  the 
node. 

traversal  of  a  relationship  *  -  Following  a  relationship  from  its  source 
node  to  its  target  node  in  the  process  of  accessing  a  node  along  a  path. 

unique  primary  name  *  -  The  pathname  associated  with  the  unique  primary 
path. 

tnique  primary  path  *  -  Every  accessible  node  can  be  traced  back  to  a 
top-level  node  by  recursively  following  PARENT  relationships;  the  path 
obtained  by  inverting  this  chain  is  the  unique  primary  path  to  the  node. 

unnamed  *  -  A  list  item  vhich  has  no  name  associated  with  it  or  a  list 
all  of  whose  items  are  unnamed. 

unobtainable  *  -  A  node  is  unobtainable  if  the  primary  relationship  of 
Which  it  is  the  target  has  been  deleted. 

user  -  A  user  is  an  individual,  project,  or  other  organizational  entity. 
In  the  GAIS  it  is  associated  with  a  top-level  node. 
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4.  GENERAL  REaUIPMUTS 


4.1  Introduction 


The  GAIS  provides  interfaces  for  data  storage  and  retrieval,  data 
transmission  to  and  fran  external  devices,  and  activation  of  programs 
and  control  of  their  execution.  In  order  to  achieve  uniformity  in  the 
interfaces,  a  single  model  is  used  to  consistently  describe  general  data 
storage,  devices  and  executing  programs.  This  provides  a  single  model 
far  understanding  the  GAIS  concepts?  it  provides  a  means  for  making 
facilities  available  equally  to  data  storage  and  program  control;  and 
it  provides  a  consistent  way  of  expressing  interrelations  both  within 
and  between  data  and  executing  programs.  This  unified  model  is  referred 
to  as  the  node  model. 


Section  4.2  discusses  how  the  interfaces  are  described  in  the  remainder 
of  Section  4  and  also  in  Section  5,  Section  4.3  describee  the  node 
model.  Section  4.4  describes  the  mandatory  and  discretionary  access 
control  model  incorporated  in  the  GAIS.  Section  4.5  describes  the 
input/output  model  used  in  the  GAIS,  Section  4.6  describes  practical 
limits  and  constraints  not  defined  by  the  interfaces.  Section  5 
provides  detailed  descriptions  of  the  interfaces. 

Appendix  A  provides  descriptions  of  the  predefined  entities  defined  in 
the  CAIS.  This  appendix  constitutes  a  mandatory  part  of  this  standard. 

Appendix  B  will  provide  a  set  of  the  Ada  package  specifications  of  the 
GAIS  interfaces  which  ccnpiles  correctly.  This  set  of  interfaces  will 
be  extracted  from  the  final  construction  of  the  CAIS  design  and  included 
in  the  Military  Standard  1  document. 


4.2  Method  of  description 


The  specifications  of  the  GAIS  interfaces  are  divided  into  two  parts: 


the  syntax  a 
specification 


defined  by  a  canonical  Ada  package 


b.  the  aamentics  as  defined  by  the  descriptions  both  of 
the  general  node  model  and  of  the  particular  padcages 
and  procedures. 


The  Ada  package  specifications  given  in  this  document  are  termed 
canonical  because  they  are  representative  of  the  form  of  the  allowable 
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actual  Ada  package  specifications  in  any  particular  AIS  inplemantation. 
The  packages  which  together  provide  an  implsnmntation  of  these 
specifications  oust  have  indistinguishable  syntax  and  senantics  from 
those  stated  herein.  The  actual  Ada  package  specifications  nay  differ 
from  the  canonical  specifications  in  the  following  ways  (which  are 
indistinguishable  to  programs  calling  these  interfaces): 

a.  The  package  nay  have  additional  WITH  or  USE  clauses. 

b.  Parameter  modes  listed  here  as  OUT  may  be  IN  CUT  or  those 
listed  as  IN  OUT  may  be  CUT. 

c.  Types  specified  as  limited  private  may  be  simply  limited 
types. 

d.  Packages  may  be  instantiations  of  generic  packages. 


The  following  differences  in  GAIS  package  inplementaticn  from  the 
specifications  in  this  docvsnant  are  NUT  permitted: 

a.  Additional  or  missing  declarations,  as  these  affect 
name  visibility. 

b.  Parameter  mode  IN  being  changed  to  IN  CUT,  as  this 
prevents  passing  of  expressions. 

c.  Limited  private  types  being  changed  to  subtypes  or 
derived  types,  when  this  changes  the  semantics  of 
'deriving'  from  the  type. 

d.  Packages  which  are  not  available  as  specified  library 
units,  because  this  changes  the  means  of  reference  to 
package  oonponerxts. 

The  interface  semantics  are  described  in  most  cases  through  narrative. 
These  narratives  are  divided  into  up  to  five  paragraphs.  The  Purpose 
paragraph  describes  the  function  of  the  interface.  The  Parameters 
paragraph  briefly  describes  each  of  the  parameters,  and  the  Exceptions 
paragraph  briefly  describes  the  conditions  under  which  each  exception  is 
raised.  Any  relevant  information  that  does  not  fall  under  one  of  these 
three  headings  is  included  in  a  Notes  paragraph.  In  cases  where  an 
interface  is  overloaded  and  the  additional  versions  are  describable  in 
terms  of  the  basic  form  of  the  interface  and/or  other  OHS  interfaces, 
these  versions  are  described  in  a  paragraph,  called  Additional 
Interfaces,  using  Ada. 

This  document  follows  the  typographical  conventions  of  [LRM],  where 
these  are  not  in  conflict  with  those  of  a  MEL-STD.  In  particular, 

a.  boldface  type  is  used  for  Ada  language  reserved  words, 
[Editor's  Note:  Typeset  docunant  only] 
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b.  UPPER  CASE  is  used  for  Ada  language  identifiers  vdiich 
are  not  reserved  words, 

c.  in  the  text,  syntactic  category  names  are  written  in 
normal  typeface  with  any  esfeedded  underscores  removed, 

d.  in  the  text,  where  reference  is  made  to  the  actual 
value  of  an  Ada  variable  (for  exanple,  a  procedure 
parameter),  the  Ada  name  is  used  in  normal  typeface. 
However,  where  reference  is  made  to  the  'Ada  object' 
itself  (see  [LBM]  3.2  for  this  use  of  the  vnrd  object), 
than  the  Ada  name  is  given  in  upper  case,  including 
any  aitoedded  underscores.  For  example,  from  [LRM] 
14.2.1  paragraphs  17,  18  and  19 

function  MXE(FIL£:  in  FH£_TYPE)  return  FH£_MDCE; 

Returns  the  current  mode  of  the  given  file, 
but 

The  exception  SEAOTS_ERROR  is  raised  if  the  file 
is  not  open. 


e.  at  the  place  where  a  technical  term  is  first  introduced 
and  defined  in  the  text,  the  term  is  given  in  an  italic 
typeface. 

[Editor's  Note*  Typeset  version  only;  this  version 
utilizes  quotation  marks  in  lieu  of  italics] 


4.3  CAIS  node  model 


The  CAIS  provides  interfaces  for  adktdnistering  entities  relevant  during 
the  softMure  lifecycle,  such  as  files,  directories,  processes  and 
devices.  These  entities  have  properties  and  may  be  interrelated  in  many 
ways. 

The  CAIS  model  uses  the  concept  of  a  "node"  as  the  carrier  of 
information  about  an  entity.  It  uses  the  concept  of  a  "relationship" 
for  representing  an  interrelation  between  two  entities  and  the  concept 
of  an  "attribute"  for  representing  a  property  of  an  entity  or  of  an 
interrelation. 

The  model  of  the  structure  vnderlying  the  CAIS  and  reflecting  the 
interrelations  of  entities  is  a  directed  graph  of  nodes,  which  form  the 
vertices  of  the  graph,  and  relationships,  which  form  the  edges  of  the 
graph.  This  model  is  a  conceptual  model.  It  does  not  iitply  that  an 
implementation  of  the  CAIS  must  use  a  directed  graph  to  represent  nodes 
and  their  relationships. 
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Both  nodes  and  relationship*  possess  attributes  describing  properties  of 
the  entities  represented  by  nodes  and  of  interrelations  represented  by 
relationships . 


4.3.1  Nodes 

The  GAXS  identifies  three  different  kinds  of  nodes:  structural  nodes, 
file  nodes  and  process  nodes.  A  node  ray  have  contents,  relationships 
and  attributes.  The  "contents"  vary  with  the  kind  of  node.  If  a  node 
is  a  "file  node",  the  contents  are  an  Ada  external  file.  The  Ada 
external  file  nay  represent  a  host  file,  a  device  (such  as  a  terminal  or 
tape  drive)  or  a  queue  (as  used  for  process  interoannunication) .  If  a 
node  is  a  "process  node",  the  contents  are  a  representation  of  the 
execution  of  an  Ada  program.  If  a  node  is  a  "structural  node",  there 
are  no  contents  and  the  node  is  used  strictly  as  a  holder  of 
relationships  and  attributes. 

Nodes  can  be  created,  renamed,  accessed  as  part  of  other  operations,  and 
deleted. 


4.3.2  Processes 

A  "process"  is  the  CMS  mechanism  used  to  represent  the  execution  of  an 
Ada  program.  A  process  is  represented  as  the  contents  of  a  process 
node.  The  process  node  and  its  attributes  and  relationships  are  also 
used  to  bind  to  an  execution  the  resources  such  as  files  and  devices 
required  by  the  process.  Taken  together,  the  process  node,  its 
attributes,  relationships  and  contents  are  used  in  the  CAIS  to  manage 
the  dynamics  of  the  execution  of  a  program. 

Each  time  execution  of  a  program  is  "initiated",  a  process  node  is 
created,  the  process  is  created,  the  necessary  resources  to  sqgport  the 
execution  of  the  program  are  allocated  to  the  process,  and  execution  is 
started.  The  newly  created  process  is  called  the  "initiated  process", 
while  the  process  which  caused  the  creation  of  that  process  in  called 
the  "initiating  process". 

A  single  CAIS  process  represents  the  execution  of  a  single  Ada  program, 
even  when  that  program  includes  multiple  tasks.  Within  the  process,  Ada 
tasks  execute  in  parallel  (proceed  independently)  and  synchronize  in 
accordance  with  the  rules  in  [U*f]  9,  paragraph  5. 

Parallel  tasks  nay  be  implemented  on  multioanputers, 
multiprocessors,  or  with  interleaved  execution  on  a 
single  physical  processor.  Gn  the  other  hand,  Whenever 
an  implementation  can  detect  that  the  same  effect  can  be 
guaranteed  if  parts  of  the  actions  of  a  given  [Ada]  task 
are  executed  by  different  physical  processors  acting  in 
parallel,  it  may  choose  to  execute  them  in  this  way;  in 
such  a  case  several  physical  processors  implement  a 
single  logical  processor. 
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Mien  a  task  makes  a  CAIS  call,  execution  of  that  task  is  blocked  until 
the  OtlS  call  returns  control  to  the  task.  Other  tasks  in  the  sane 
process  nay  continue  to  execute  in  parallel,  subject  to  the  Ada  tasking 
rules.  If  calls  on  a  CAIS  interface  are  enacted  concurrently,  the  CAIS 
does  not  specify  their  order  of  execution. 

Processes  are  analogous  to  Ada  tasks  in  that  they  execute  logically  in 
parallel,  have  mechanisms  for  interprocess  synchronization,  and  can 
exchange  data  with  other  processes.  However,  processes  and  Ada  tasks 
are  dissimilar  in  certain  critical  ways.  Data,  procedures  or  tasks  in 
one  process  cannot  be  directly  referenced  from  another  process.  Also, 
while  tasks  in  a  program  are  bound  together  prior  to  execution  time  (at 
aompile  or  link  time),  processes  are  not  bound  together  except  by 
cooperation  using  CAIS  facilities  at  run  time. 


4.3.3  Relationships  and  relations 

The  relationships  of  CAIS  nodes  form  the  edges  of  a  directed  graph; 
they  are  used  to  build  conventional  hierarchical  directory  and  process 
structures  (see  Section  5. 1.5  CAIS^STHUCnjRALJXXBS,  Section  5.2.2 
CAIS_PfOCES5_QCMnUL)  as  well  as  arbitrary  directed-graph  structures. 
Relationships  are  unidirectional  and  are  said  to  emanate  from  a  "source 
node"  and  to  terminate  at  a  "target  node".  A  relationship  may  also  have 
attributes  describing  properties  of  the  relationship. 

Because  any  node  may  have  many  relationships  representing  many  different 
classes  of  connections,  the  concept  of  a  "relation"  is  introduced  to 
categorize  the  relationships.  These  relations  identify  the  nature  of 
relationships,  and  relatiorahips  are  instances  of  relations.  Certain 
basic  relations  are  predefined  by  the  CAIS.  Their  semantics  are 
explained  in  the  following  sections.  Additional  predefined  relations 
are  introduced  in  Section  5  and  are  listed  in  Appendix  A.  Relatione  may 
also  be  defined  by  a  user.  The  CAIS  associates  only  the  relation  name 
with  user-defined  relations;  no  other  semantics  are  supported. 

Each  relationship  is  identified  by  a  relation  name  and  a  relationship 
key.  The  "relation  nans"  identifies  the  relation,  and  the  "relationship 
key"  distinguishes  between  multiple  relationships  each  bearing  the  same 
relation  name  and  emanating  from  a  given  node.  In  this  document,  a 
relation  name  is  oftsn  referred  to  sisply  as  a  relation  and  a 
relationship  key  is  often  referred  to  sisply  as  a  key. 

Nodes  in  the  environment  are  attainable  by  navigating  along  the 
relationships.  Operations  are  provided  to  move  from  one  node  (along  one 
of  its  relationships)  to  a  connected  node  (see  Section  4.3.4). 
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4. 3. 3.1  Kinds  of  relationships 

There  are  two  kinds  of  relationships:  primary  and  secondary.  When  a 
node  is  created,  an  initial  relationship  is  established  from  some  other 
node.  This  initial  relationship  is  marked  as  the  "primary  relationship" 
to  this  new  node,  and  the  source  node  of  this  initial  relationship  is 
called  the  "parent"  node.  In  addition,  the  new  node  will  be  connected 
back  to  this  parent  via  the  predefined  PARENT  relation.  Primary 
relationships  form  a  strictly  hierarchical  tree.  There  is  no 
requirement  that  all  primary  relationships  emanating  frqn  a  node  have 
the  same  relation  name.  The  primary  relationship  is  broken  by 
DELETE_NOCC  or  MUTEJME  operations  (see  Section  5.1.2) .  After  such 
deletion  the  node  is  said  to  be  "unobtainable" .  A  "non-existing  node" 
is  one  which  has  never  been  created.  RENMC  operations  (see  Section 
5.1.2.19)  may  be  used  to  make  the  primary  relationship  emanate  from  a 
different  permit.  The  operations  DELEIEJSIODE,  DEXETE_TKEE,  RENAME,  and 
the  operations  creating  nodes  are  the  only  ones  that  manipulate  primary 
relationships.  They  maintain  a  state  in  which  each  node  has  exactly  one 
parent  and  a  unique  primary  name  (see  Section  4.3.4).  "Secondary 
relationships"  are  arbitrary  connections  vhich  may  be  established 
between  two  existing  nodes;  secondary  relationships  may  form  an 
arbitrary  directed  graph.  User-defined  secondary  relationships  are 
created  with  the  LINK  procedure  (see  Section  5.1.2.22)  and  broken  with 
the  UNLINK  procedure.  Secondary  relationships  may  exist  to  unobtainable 
nodes. 


4. 3. 3. 2  Basic  predefined  relations 

The  CAIS  predefines  certain  relations.  Relationships  belonging  to  a 
predefined  relation  cannot  be  created,  modified,  or  deleted  by  means  of 
the  QVIS  interfaces,  except  where  explicitly  noted.  The  semantics  of 
the  predefined  relations  which  are  basic  to  the  node  model,  as  well  as 
related  concepts  of  the  CAIS,  are  explained  in  this  Section  and  Section 
4.4. 

The  CAES  identifies  the  following  basic  predefined  relations:  PARENT, 
USER,  DEVICE,  JOB,  OJRRENTJOB,  CURRENTJJSER,  CUFRENTJCDE. 

The  CATS  node  model  incorporates  the  notion  of  a  user.  Each  user  has 
one  "top-level  node"  (similar  to  a  file-system  directory).  This 
top-level  node  is  an  entry  point  to  the  CAIS  directed  node  graph  and 
from  it  the  user  can  access  other  structural,  file  and  process  nodes. 

The  CAIS  node  model  incorporates  the  notion  of  a  "system"  node  which 
acts  as  the  root  of  the  entire  CAIS  node  structure.  Each  top-level  node 
is  reachable  from  the  system  node  along  a  primary  relationship  of  the 
predefined  relation  USER  emanating  frcm  the  system  node.  The  key  of 
this  relationship  is  the  "user  name".  Each  user  name  has  a  top-level 
node  associated  with  it.  The  system  node  is  not  manipulable  via  the 
CAIS  interfaces.  It  may  only  be  manipulated  by  interfaces  outside  the 
CAIS,  e.g. ,  to  add  new  USER  relationships  emanating  from  the  system 
node. 
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A  "user"  may  be  an  individual,  project,  or  other  organizational  entity; 
this  notion  is  not  equated  with  an  individual  person.  It  is  left  to 
each  OVIS  inplsmBirtaticn  to  set  vp  a  methodology  for  users  to  enter  the 
APSE  and  for  enforcing  any  constraints  that  limit  the  tq^level  nodes  at 
vAiich  users  may  enter  the  APSE.  After  entering  the  APSE,  the  user  will 
be  regarded  by  the  OVIS  as  the  user  associated  with  the  top-level  node 
at  Which  he  entered  the  APSE. 

✓ 

The  OVIS  node  model  incorporates  the  notion  of  devices.  Each  device  is 
described  by  a  file  node.  This  file  node  is  reachable  fran  the  system 
node  along  a  primary  relationship  of  the  predefined  relation  DEVICE 
emanating  from  the  system  node.  The  key  of  this  relationship  is  the 
"device  name".  The  CAIS  does  not  define  interfaces  for  creating  nodes 
which  represent  devices;  such  interfaces  are  to  be  provided  outside  the 
OVIS. 

When  a  user  enters  the  APSE,  a  "root  process"  node  is  created  which 
often  may  represent  a  ocnmand  interpreter  or  other  user-ccmmunicaticn 
process.  A  process  node  tree,  spanned  by  primary  relationships, 
develops  from  this  root  node  as  other  processes  (celled  "dependent" 
processes)  are  initiated  for  the  ueer.  A  particular  user  may  have 
entered  the  APSE  several  times  concurrently.  Each  corresponding  process 
node  tree  is  referred  to  as  a  "job".  The  predefined  JOB  relation  is 
provided  for  locating  each  of  the  root  process  nodes  firm  the  user's 
top-level  node.  A  primary  JOB  relationship  annates  from  each  user's 
top-level  node  to  the  root  process  node  of  each  of  the  user's  jobs. 

The  OVIS  does  not  specify  an  interface  far  creating  the  initial  root 
process  node  then  a  user  enters  the  APSE,  but  the  OVIS  node  model 
requires  that  secondary  USER  and  DEVICE  relationships  with  the 
appropriate  ueer  and  device  names  as  keys  emanate  from  the  root  process 
node  to  all  top-level  nodes  to  whidi  this  user  has  access  rights  (see 
Section  4.4)  and  that  these  USER  and  DEVICE  relationships  are  inherited 
by  the  rest  of  the  process  nodes  in  the  job.  Top-level  nodes  of  other 
users  and  devices  can  therefore  be  reached  from  a  process  node  using  the 
relation  USER  or  DEVICE  and  a  relationship  key  which  is  interpreted  as 
the  respective  user  or  device  name. 

Any  process  node  in  a  job  has  associated  with  it  at  least  three 
additional  predefined  secondary  relationships.  The  predefined 
CURRENT  JOB  relationship  always  points  to  the  root  node  far  a  process 
node's  lob.  The  predefined  CURRQR'JJSBt  relationship  always  points  to 
the  user's  top-level  node.  The  predefined  CURRENT_NODE  relationship 
alumys  points  to  a  node  which  represents  the  process's  current  focus  or 
context  for  its  activities.  The  process  node  can  thus  use  the 
CURRENT  NODE  for  a  base  node  when  specifying  paths  (see  Section  4.3.4). 
All  tfiree  of  these  relations  (CURRENT  JOB,  CURRENTUSER,  and 
CUFRENTJJOOE)  provide  a  convenient  means  for  identifying  (see  Section 
4.3.4)  other  CAIS  nodes.  The  CAIS  requires  that  the  root  process  node 
created  whan  the  user  enters  the  APSE  has  a  CURRENT_NODE  relationship 
pointing  to  the  top-level  node  for  the  user. 
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The  node  model  also  usee  the  concept  of  "current,  process".  This  is 
implicit  in  all  calls  to  CAIS  operations  and  refers  to  the  process  for 
the  currently  executing  program  asking  the  call.  It  defines  the  context 
in  vAiich  the  panmeters  are  to  be  interpreted.  In  particular#  paths  are 
determined  in  the  aontext  of  the  current  process. 


4.3.4  Paths  and  pathnames 

Every  accessible  node  may  be  reached  by  following  a  sequence  of 
relationships;  this  sequence  is  called  the  "path"  to  the  node.  A  path 
starts  at  a  known  (not  necessarily  top-level)  node  and  follows  a 
sequence  of  relationships  to  a  desired  node.  The  starting  node  is 
called  the  "base"  node.  Every  accessible  node  can  be  traced  back  to  a 
top-level  node  by  following  PARENT  relationships;  the  path  obtained  by 
inverting  this  chain  is  the  "tnique  primary  path"  to  the  node. 

Paths  are  specified  using  a  pathname  syntax.  Starting  from  a  given 
node,  a  path  is  followed  by  traversing  a  sequence  of  relationships  until 
the  desired  node  is  reached.  The  "pathname"  for  this  path  is  mode  up  of 
the  concatenation  of  the  names  of  the  traversed  relationships  in  the 
same  order  in  which  they  are  encountered.  The  pathname  associated  with 
the  unique  primary  path  is  called  the  "unique  primary  name"  of  the  node. 
The  base  node  of  a  path  may  be  identified  explicitly  as  an  additional 
argument,  the  BASE,  to  many  of  the  CAIS  operations,  signaling  the 
starting  point  for  interpretation  of  a  pathname.  Otherwise,  the  current 
process  node  is  used  as  the  starting  point  for  interpretation  of  the 
pathname.  The  unique  primary  name  of  a  node  is  syntactically  identical 
to,  and  therefore  can  be  used  as,  a  pathname  whose  interpretation  starts 
at  the  current  process  node. 

"Identification"  of  a  node  is  provided  by  a  pathname  or  a 
base/kay/relation  name.  The  phrase  "toidantify"  means  to  provide  an 
identification  for  a  node.  A  node  identification  is  considered 
“illegal"  if  either  the  pathname  or  the  relationship  key  or  relation 
name  are  syntactically  illegal  with  respect  to  the  syntax  defined  in 
Table  I  below.  An  illegal  identification  is  treated  as  an 
identification  for  a  non-existing  node. 

A  pathname  implies  M traversalof anode "  if  a  relationship  emanating  from 
the  node  is  traversed;  consequently  all  nodes  on  the  path  to  a  node  are 
traversed,  while  the  node  at  the  end  of  the  path  is  not  traversed.  An 
identification  that  would  require  traversal  of  an  vnobtainable  or 
inaccessible  node  is  treated  as  the  identification  for  a  non-existing 
node. 

Many  CAIS  operations  allow  the  emission  of  the  relation  name  when 
referring  to  a  relationship,  defaulting  it  to  'DOT'.  Relationship  keys 
of  DOT  relationships  may  not  be  the  erpty  string.  Instances  of  the  DOT 
relation  are  fully  manipulahle  by  the  user  within  access  right 
constraints.  DOT  relationships  are  not  restricted  to  be  primary 
relationships  and  are  not  associated  with  any  other  CAIS-specific 
semantics. 
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The  syntax  of  a  pathname  is  a  sequence  of  path  elements,  each  "path 
element"  representing  the  traversal  of  a  single  relationship.  A  path 
element  is  an  apostrophe  (pronounced  'tide')  followed  by  a  relation  name 
and  a  parenthesized  relationship  key.  If  the  relationship  key  is  the 
eepty  string,  the  parentheses  may  be  omitted.  Thus,  'PARENT  and 
' PARENT ()  refers  to  the  same  node.  If  the  relation  is  DOT,  than  the 
path  element  may  be  represented  ainply  by  a  dot  ( ' . ' )  followed  by  the 
key  for  the  DOT  relation.  Thus,  'DOT(OCNTROU£R)  is  the  same  as 
.CXimCLLER  . 

A  pathname  nay  begin  siiqply  with  a  relationship  key,  not  prefixed  by 
either  an  apostrophe  or  ' . '  .  This  is  taken  to  mean  interpretation 
following  a  relationship  of  the  CURRENT_NCCE  with  the  relation  name  DOT 
and  with  the  given  key.  Thus  —  AIRPORT  is  the  same  as 
1  aJRREOT_NOCE  .AIRPORT  . 

A  pathname  may  also  consist  of  just  a  single  ' . 1  .  This  is  interpreted 
as  referring  to  the  current  process  node. 

Relation  mw—  and  relationship  keys  follow  the  syntax  of  Ada 
identifiers.  Upper  and  lower  case  are  treated  am  equivalent  within  such 
identifiers.  For  exanple,  all  of  the  following  are  legal  node 
pathnames,  and  they  would  all  refer  to  the  same  node  if  the  CURRENr_NODE 
were  'USER(JUNES)  .TRACKER  and  the  CURRENT JJSER  ware  JUNES  : 

a.  Landing_Systan '  With_uni t  ( Radar ) 

b.  'User  (Jones)  .TRACKER.  Landing_system,withJJNIT(RAEAR) 

c.  '  OJKREOTJJSm.TRACKER.  LANDINGJSYSTEM  'WnH_unit  (radar) 

By  convention,  a  relationship  key  ending  in  '  '  is  taken  to  represent 
the  LATEST  KEY  ( lexicographically  last).  Whan  creating  a  node  or 
relationship,  use  of  '  1  to  and  the  final  key  of  a  pathname  will  cause  a 
key  to  be  autonatically  assigned,  lexicographically  following  all 
previous  keys  far  the  same  relation  and  initial  relationship  key 
character  sequence. 
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4.3.5  Attributes  - 

Both  nodes  and  relationships  nay  have  attributes  which  provide 
information  about  the  node  or  relationship.  Attributes  are  identified 
fay  an  attribute  name.  Each  attribute  (see  Section  5.1.3 
CAES_ATTRIBUTES)  has  a  list  of  the  values  assigned  to  it,  represented 
using  the  CAISJLISTJJITLITIES  (see  Section  5.4.1)  type  called  LISTTXFE. 

Relation  names  and  attribute  names  both  have  the  same  form  (that  is,  the 
syntax  of  an  Ada  identifier).  Relation  names  and  node  attribute  names 
a  given  node  must  be  different  frcm  each  other. 

CATS  predefines  certain  attributes  which  are  discussed  in  Section  5 
listed  in  Appendix  A.  Predefined  attributes  cannot  be  created, 
fied  or  deleted  fay  the  user,  except  where  explicitly  noted. 


TABLE  I.  Pathname  ENF 


path_name:  :■  (path  element}  I 

relatXonshipJcey{path_element}  I 


pathjelementi :»  'relation  name  [  (  relationship_key  )  ]  I 
. relationship Jcey 


relation_name: :  "identifier 
relationshipjcey: :  “identifier  |  identifier  # 


Notation: 

1.  Words  -  syntactic  categories 

2.  [  ]  -  optional  items 

3.  {  }  -  an  item  repeated  zero  or  more  times 

4  |  -  separates  alternatives 
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4.4  Discretionary  and  mandatory  access  control 


The  CMS  specifies  mechanisms  for  discretionary  and  nandatory  access 
control.  In  the  CAIS,  the  following  operations  constitute  "access  to  a 
node":  reading  or  writing  of  the  contents  of  the  node,  reading  or 

writing  of  attributes  of  the  node,  reading  or  writing  of  relationships 
emanating  from  a  node  or  of  their  attributes,  querying  the  kind  of  a 
node,  and  traversing  a  node  as  inplied  by  a  pathname.  The  phrase 
*  reading  relationships'  is  a  convenient  short-hand  for  either  traversing 
relationships  or  reading  their  attributes.  To  access  a  node,  then, 
means  to  perform  any  of  the  above  access  operations.  The  phrase  'to 
obtain  access'  to  a  node  means  being  permitted  to  perform  certain 
operations  an  the  node  within  access  right  constraints. 

In  the  CAIS,  the  following  operations  do  not  constitute  access  to  a 
node:  closing  node  handles  to  a  node,  opening  a  node  with  intent 
EXISTENCE  (see  Table  v  ),  reading  or  writing  of  relationships  of  vrtiich  a 
node  is  the  target  or  of  their  attributes,  and  querying  the  status  of 
node  handles  to  a  node. 

In  the  CMS  "access  control"  refers  to  all  the  aspects  of  controlling 
access  to  information,  it  consists  of: 

1.  "access  rights":  descriptions  of  the  types  of  operations  which 

can  be  performed  (See  Section  4. 4. 1.2). 

2.  "access  control  rules":  the  rules  describing  the  correlations 

between  access  rights  and  intents. 

3.  "access  checking":  the  operation  of  checking  access  rights 

with  intents  according  to  the  access  control 
rules  and  either  permitting  or  denying  the 
intended  operation. 

All  of  the  information  required  to  perform  access  checking  is 
collectively  referred  to  as  "access  control  information.”  The  resulting 
restrictions  placed  on  certain  kinds  of  operations  by  access  control  are 
called  "access  rights  constraints." 

A  node  is  "inaccessible"  if  the  currant  process  does  not  have  sufficient 
discretionary  access  control  rights  to  have  knowledge  of  the  node's 
existence  or  if  mandatory  access  controls  prevent  information  flow  from 
ths  node  to  the  current  process.  The  property  of  inaccessibility  is 
always  relative  to  the  access  rights  of  the  currently  executing  process, 
vhile  the  property  of  unObtainability  is  a  property  of  the  node  being 
accessed. 

These  concepts  and  the  CAIS  mechanisms  which  support  than  are  discussed 
in  the  following  sections. 
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4.4.1  Discretionary  access  control 

Discretionary  access  control  limits  authorized  access  to  nodes  to  named 
users  or  groups  of  users,  the  establishment  of  access  rights  to  an 
object  is  performed  by  an  authorized  user,  typically  the  creator  of  the 
object. 

In  the  OVIS,  an  "Object"  is  any  node  to  be  accessed  and  a  "subject"  is 
any  process  node  (acting  an  the  behalf  of  a  given  user)  performing  an 
operation  requiring  access  to  an  object  node. 

Normally,  a  user  may  adopt  one  or  more  roles  in  order  to  affect  sane 
purpose.  In  these  roles,  the  user  may  be  acting  as  himself,  acting  on 
behalf  of  another  person,  acting  as  a  member  of  seme  group,  or  acting 
with  sane  rights  granted  him  as  a  result  of  the  function  being 
performed.  The  roles  a  user  has  adopted  are  one  factor  used  in 
determining  access  rights.  In  the  OVIS,  a  subject  (process  node)  nay 
act  in  the  capacity  of  one  or  more  roles.  Each  role  identifies  a  CMS 
user,  a  program  being  executed,  or  a  particular  group  of  users, 
programs,  or  sub-groups. 

In  the  OVIS,  a  "role"  may  be  a  user  tap-level  node,  a  program  node,  or  a 
group  node.  A  "program  node"  is  the  file  node  containing  As  executable 
image  of  the  program.  Roles  can  be  grouped  by  a  "group  node"  which  is  a 
structural  node  with  emanating  relationships  identifying  eadh  of  the 
group's  members;  a  group  member  may  be  either  an  individual  user  node, 
a  program  node,  or  another  group  node.  For  exanple,  a  group  node  may 
have  as  its  manbers  all  nodes  representing  compatible  versions  of  the 
oaipiler  or  a  collection  of  tools  designed  to  operate  on  a  given  type  of 
data,  or  a  group  node  may  have  as  its  manbers  all  nodes  representing 
individuals  on  a  particular  project  or  all  subunits  of  a  particular 
organization. 

Each  group  member  is  identified  either  by  a  primary  relationship  of  the 
predefined  relation  PEFMANBJT_MEMBER  or  by  a  secondary  relationship  of 
the  predefined  relation  POTENfXAL_MEMBTO,  emanating  from  the  group  node. 
The  primary  PEFMANENTJfiMBER  relationship  is  used  to  identify  those 

manbers  that  are  considered  "permanent  manbers"  of  a  given  group.  The 
secondary  relationship  P0TEOTIAL_MEMBE3l  is  used  to  identify  those 

members  that  may  dynamically  acquire  membership  in  the  group.  The 
phrase  "potential  menber"  of  a  group  refers  to  any  role  that  is  the 
target  of  a  POTENTIAL_MB«BER  relationship  ffran  that  group  or  from  any  of 
that  group's  descendants. 

The  primary  relation  PERMANENT  MEMBER  may  be  used  to  create  a  hierarchy 
of  roles  by  defining  members  of  i a  group  that  are  themselves  groups.  A 
user  top-level  node  may  not  be  the  target  of  a  primary  PEFMANENT_MEMBER 
relationship  emanating  from  a  group  node,  due  to  the  restriction  that 
user  top-level  nodes  must  have  the  system  node  as  their  parent.  The 
phrase  "descendant  of  a  group"  refers  to  ary  role  reachable  from  the 
given  group  via  primary  PREMANENT_MEMBER  relationships.  The  phrase 
"ancestor  of  a  role"  refers  to  ary  group  reachable  from  the  given  role 
via  PARENT  relationships.  Hence,  only  nodes  that  represent  permanent 
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members  of  a  group  have  ancestors. 

The  CMS  discretionary  access  control  model  requires  that,  upon  creation 
of  a  root  process  node,  secondary  relationships  of  the  predefined 
relation  KX£  emanate  from  the  created  root  prooess  node  to  an 
inplmoantation-defined  set  of  roles;  at  least  the  secondary  R CLE 
relationship  with  the  user  name  as  key  must  be  established  from  the  root 
process  node  to  the  user  top-level  node.  These  RCCE  relationships  are 
inherited  by  the  prooess  nodes  initiated  on  behalf  of  the  user  (similar 
to  USER  and  DEVICE  relationships).  Roles  can  therefore  be  reached  from 
a  process  node  with  the  relation  ROLE  and  a  relationship  key  interpreted 
to  be  the  role  name. 


4. 4. 1.1  Adopting  a  role 

When  a  process  "adopts"  a  particular  role,  a  secondary  relationship  of 
the  predefined  relation  ADOPIED_RCC£  is  created  from  the  process  node  to 
the  role.  There  nay  be  multiple  ADOPIH)__RCL£  relationships  emanating 
from  a  process  node.  The  phrase  "adopted  role  of  a  prooess”  refers  to 
the  role  ,  or  ancestor  of  tits  role,  that  is  the  target  of  an 
ADGPTH)_RGLE  relationship  from  the  process  nods.  Roles  are  adopted 
either  inplicitly  or  explicitly,  ffien  a  process  is  created,  it 
implicitly  adopts  the  program  node  for  the  program  it  is  executing. 
When  a  root  process  node  is  created,  it  implicitly  adopts  its  current 
user  node.  When  any  process  node  is  created,  it  inplicitly  inherits  the 
AK)PTED_RQLE  relationships  of  the  node  of  its  creating  process.  A 
process  may  explicitly  adopt  a  group  using  the  ADOPT  procedure  (Section 
5. 1.4.4).  For  a  process  to  adopt  a  given  group,  sans  other  role  the 
prooess  has  already  adopted  must  be  a  potential  member  of  the  groip  to 
be  adopted. 


4.4.1. 2  The  access  relationship  <*nd  the  privilege  attribute 

An  access  relationship  is  ary  secondary  relationship  of  the  predefined 
relation  ACCESS  from  an  abject  to  a  role.  Ary  object  may  have  zero  or 
more  access  relationships.  Each  access  relationship  has  a  predefined 
privilege  attribute,  called  GRANT,  whidh  specifies  vfoat  access  rights  to 
the  object  are  granted  to  adopters  of  the  role. 

The  privilege  attribute  value  acnsists  of  a  list  of  "privilege 
specifications " .  Each  privilege  specification  aonsists  of  a  necessary 
privileges  list,  followed  by  a  right-arrow  (■>),  followed  by  a  resulting 
privileges  list.  A  list  with  one  element  may  be  replaced  by  the  element 
alone.  If  the  necessary  privileges  list  is  empty,  the  privilege 
specification  may  be  replaced  by  the  resulting  privilege  list  alone. 
The  for  the  ENF  privilege  specifications  is  given  in  Table  II. 
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TABLE  XI.  Privilege  Specification  ENF 


privilegejspedficaticn:  i«  (  [  naceasary_privileges  »>  3 

resulting_privileges  ) 

necessary_privileges:t>  privilege_list 
resulting_privileges  s *■  privilege_list 


privilege_list 


: :a  identifier  I 
(  identifier  {  ,  identifier)  ) 


Notations 

1.  Wards  -  syntactic  categories 

2.  [  ]  -  optional  items 

3.  {  )  -  an  item  repeated  zero  or 

4  |  -  spearates  alternatives 


mare  times 


The  necessary  and  resulting  privileges  lists  are  lists  of  privilege 
names.  Privilege  names  imply  the  granting  of  certain  accees  rights.  A 
privilege  name  has  the  syntax  of  an  Ada  identifier.  Privilege  names  may 
be  user-defined,  but  certain  privilege  names  have  special  significance 
to  CAES  operations.  In  particular,  the  (AES  recognizes  the  privilege 
names  given  in  Table  III  and  the  access  rights  for  vftiidi  they  are 
necessary  or  sufficient. 


TABLE  III.  Privilege 


Rights 


RELATIONSHIPS 


Without  this  access  right,  ths  object  is 
inaccessible  to  the  subject.  Without  additional 
access  rights,  subject  may  neither  read  nor 
write  attributes,  relationships  or  contents  of 
the  object. 

subject  may  read  attributes  of  relationships 
emanating  from  the  object  or  use  it  far 
traversal  to  another  nods;  the  access  right 
EXISTENCE  is  implicitly  granted.  Necessary  to 
open  the  object  with  intent  READ  RELATIONSHIPS. 
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WRITE_REXAnCNSHIPS  subject  may  create  cr  delete  relationships 

emanating  frtm  the  object  or  nay  create,  delete, 
or  modify  attributes  of  these  relationships;  the 
access  right  EXISTENCE  is  implicitly  granted. 
Necessary  to  open  the  abject  with  intent 
WRITE_RELAnCWSHIPS . 

REAt  ATTRIBOTES  subject  may  read  attributes  of  the  abject; 

the  access  right  BCIS1B ICE  is  implicitly  granted 
Necessary  to  open  the  abject  with  intent 
READJflTRIBUTES. 

WRITE_ATTRIBl/rES  subject  nay  create,  write,  or  delete  attributes 

of  the  object;  the  access  right  EXISTENCE  is 
implicitly  granted.  Necessary  to  open  the  object 
with  intent  WRITE  ATTRIBUTES. 


READ  0CNTQ7TS  subject  may  read  contents  of  the  abject;  the 

access  right  EXISTENCE  is  implicitly  granted. 
Necessary  to  open  the  abject  with  intent 
READ  CCNTENTS. 


WRETEjCGNTOflS  subject  may  write  contents  of  the  object;  the 

access  right  EXISTENCE  is  implicitly  granted. 
Necessary  to  open  the  object  with  intent 
wRnE_axrrENrs. 

READ  union  of  READJRELATICNSHIPS,  READJVTTRIBUTES, 

READJZKIENTS,  and  BOSIENCE  access  rights. 
Necessary  to  open  the  abject  with  intent  READ. 
Sufficient  to  open  the  abject  with  intent 
READ_REUTICNSHIPS,  READ_A3TRIR7TES,  or 
READ  OCNTEOTS. 


WRITE  union  of  WRITE_RELAnCNSHIPS,  WRITE^ATIRIBUTES, 

WRITEJXNTQrrS,  and  EXISTENCE  access  rights. 
Necessary  to  open  the  object  with  intent  WRITE. 
Sufficient  to  open  the  abject  with  intent 
WRITE J^EIATCONSHIPS,  WRITE JOTRIBUTES,  or 

write  axnrars. 


BCBCUTE  subject  may  create  a  process  that  takes  the 

object  as  its  executable  image;  the  access  right 
EXISTENCE  is  implicitly  granted.  Necessary  to 
open  the  object  with  intent  EXECUTE. 

subject  may  modify  access  control  information  of 
the  object;  the  access  right  EXISTENCE  is 
implicitly  granted.  Necessary  to  open  the  object 
with  intent  OCNTRCL. 
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The  following  are  examples  of  privilege  specifications : 


(READ,  WRITE,  APPQJD_MAIL) 

(oopile,  aotmaD 

((EDIT,  OCM»ILE)->(READ,  WRITE  GOHrOHS)) 
(PEAEMAI1>> (READ,  WRITE),  SENMAH/->APPBD) 


Aooeee  relaticnshipe  and  privilege  attributes  are  established  for 
objects  using  the  interfaces  provided  in  the  padcage  CAIS  ACCESS J3OTRCL 
or  nay  be  established  at  node  creation.  When  a  node  Is  created,  the 
initial  access  control  information  may  be  sipplied  by  the  ACXXSS_OCNXKJL 
parameter.  If  non-null,  this  parameter  specifies  the  initial  access 
control  information  to  be  established  for  the  created  node,  using  named 
Ada  aggregate  syntax.  Each  named  choice  given  in  the  ACCESS J2KTR0L 
parameter  identifies  a  RQL£  relationship  key.  Each  selected  expression 
identifies  a  privilege  specification.  For  each  of  the  component 
associations,  an  access  relationship  is  created  from  the  created  node  to 
a  role  identified  by  the  pathname  built  from  the  relation  ROLE  and  the 
relationship  key  given  by  the  choice.  The  privilege  specification  is 
the  initial  value  of  the  GRANT  attribute  of  the  aooees  relationship. 


4. 4.1. 3  Discretionary  access  checking 

When  access  control  is  enforced  for  a  given  operation,  each 
discretionary  access  right  required  for  each  object  involved  in  the 
operation  is  aospared  to  the  process's  access  rights  as  defined  by  the 
abject  access  relationships.  If  the  object  has  an  access  relationship 
to  a  role  that  is  an  adopted  role  of  the  subject  and  the  relationship 
allows  the  access  right  being  checked,  than  the  operation  is  allowed. 
Otherwise  the  operation  is  not  allowed,  and  the  operation  is  terminated 
by  raising  an  exception. 

For  an  access  relationship  to  grant  an  aocesa  right,  the  access  right 
must  appear  in  a  resulting  privilege  list  in  a  GRANT  attribute  of  the 
relationship,  and  the  access  rights  in  the  associated  required  privilege 
list  must  have  been  granted. 


4.4.2  Mandatory  access  control 

Mandatory  access  control  provides  access  controls  "based  directly  on  a 
ccnpariscn  of  the  individual's  clearance  or  authorization  for  the 
information  and  the  classification  or  sensitivity  designation  of  the 
information  being  sought."  [TCSEC] 

A  mandatory  access  control  classification  may  be  either  a  hierarchical 
classification  level  or  a  nan-hierarchical  category.  A  hierarchical 
classification  level  is  chosen  from  an  ordered  set  of  classification 
levels  and  represents  either  the  sensitivity  of  the  abject  or  the 
trustworthiness  of  the  subject.  In  hierarchical  classification,  the 
reading  of  information  flows  downward  towards  less  sensitive  areas. 
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while  the  creating  of  information  flows  ipuard  towards  more  trustworthy 
individuals.  A  subject  nay  obtain  read  access  to  an  abject  if  the 
hierarchical  classification  of  the  subject  is  greater  than  or  equal  to 
that  of  the  object.  In  turn*  to  obtain  write  access  to  the  object,  a 
subject's  hierarchical  classification  must  be  less  than  or  equal  to  the 
hierarchical  classification  of  the  abject. 

Each  sih ject  and  abject  is  assigned  zero  or  more  ncn-hierardiical 
categories  which  represent  coexisting  classifications .  A  subject  may 
obtain  read-access  to  an  abject  if  the  set  af  nan-hierarchical 
categories  assigned  to  the  subject  contains  each  aategory  assigned  to 
the  abject.  likewise,  a  subject  may  obtain  write  access  to  an  abject  if 
each  of  the  non-hierar&ical  categories  assigned  to  the  subject  are 
included  in  the  set  of  categories  assigned  to  the  object. 

A  subject  must  satisfy  both  hierarchical  and  ncn-hierarchical  access 
rights  constraints  to  obtain  access  to  an  abject. 

In  the  CATS,  subjects  are  CAIS  processes.  While  an  object  may  be  any 
CAIS  node.  Operations  are  CAIS  operations  and  are  classified  as  read, 
write,  or  read/write  operations.  Access  checking  is  performed  at  the 
time  the  operation  is  requested  by  acapering  the  classification  of  the 
subject  with  that  of  the  abject  with  respect  to  the  type  of  operation. 


4.4. 2.1  Labeling  of  CAIS  nodes 

The  labeling  of  nodes  is  provided  by  predefined  node  attributes.  A 
predefined  attribute,  called  SUBJECT  CLASSIFICATION,  is  assigned  to  each 
process  node  and  represents  the  nbSe's  classification  as  a  subject.  A 
predefined  attribute,  called  GBJBCTjXASSIFIGKnON,  is  assigned  to  each 
node  and  represents  the  node's  classification  as  an  abject.  These 
attributes  have  limited  functionality  and  cannot  be  read  or  written 
directly  through  the  QMS  interfaces.  The  value  of  the  attribute  is  a 
parenthasized  list  containing  two  items,  the  hierarchical  classification 
level  and  the  ncn-hiararchical  category  list.  The  hierarchical 
classification  is  a  keyword  nrnnbar  of  the  ordered  set  of  hierarchical 
classification  keywords.  The  non-hiararchical  category  list  is  a  list 
of  zero  or  more  keyword  nmpberz  of  the  set  of  ncn-hierarchical 
categories.  For  example,  the  following  are  possible  classification 
attribute  values* 


(TOP_SBCREr,  (MAELJJSER,  OPERATOR,  STAFF)) 
(UNCLASSIFIED,  ()) 


(SECRET,  (STAFF)) 

The  ENF  for  the  value  of  a  participant  classification  attribute  is  given 
in  Table  IV. 
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TABLE  IV.  Participant  Classification  Attribute  Value  BNP 


object_classification  »■  classification 
subject  classification  1 1«  classification 
classification  (  hierarchicaljelaasification, 

ncnjiierarchioal  categories  ) 
hierarchical  classification  i  :■  keywo rtf” 

nonJiierarchTcaljoategoiries  **-  (  [  keyword  (  ,  keyword  }  ]  ) 
keyword  x  :*  identifier 


Notation: 

1.  Words  -  syntactic  categories 

2.  [  ]  -  optional  itons 

3.  {  }  -an  item  repeated  zero  or  more  times 
4  I  -  spsarates  alternatives 


The  hierarchical  classification  level  set  and  the  ncn-hierarchical 
category  set  are  inplementation-defined. 


4.4.2. 2  Labeling  of  subject  nodes 

When  a  root  process  is  created,  it  is  assigned  subject  and  object 
classification  labels.  The  method  by  tftiidi  these  initial  labels  are 
assigned  is  not  specified;  however,  the  labels  "shall  accurately 
represent  security  levels  of  the  specific  [users]  with  v*ii<h  they  are 
associated."  [TCSBC]  When  any  non-root  (dependant)  process  node  is 
created,  the  creator  may  specify  the  classification  attributes 
associated  with  the  node.  If  no  classification  is  specified,  the 
classification  is  inherited  from  the  creator.  The  assigned 
classification  must  adhere  to  the  requirements  for  mandatory  access 
control  over  write  operations. 
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4.4.2. 3  Labeling  of  abject  nodes 

When  a  non-process  object  is  created,  it  is  assigned  an  object 
classification  label.  The  classification  label  may  be  specified  in  the 
create  operation,  or  it  nay  be  inherited  fran  the  parent.  The  assigned 
classification  must  adhere  to  the  requirements  for  mandatory  access 
control  over  write  operations. 


4. 4. 2. 4  Labeling  of  nodes  for  devices 

Certain  file  nodes  representing  devices  may  have  a  range  of 
classification  levels.  The  classification  label  of  the  node  of  the 
process  opening  one  of  these  nodes  is  assigned  to  the  file  node  vfaile  it 
is  open. 

The  range  of  classification  levels  is  specified  by  two  predefined  CAIS 
node  attributes.  The  attribute  HIGHESTjCXASSIFICATICN  defines  the 
highest  allowable  abject  classification  label  that  may  be  assigned  to 
the  file  node.  The  attribute  LOWEST  CLASSIFICMTCN  defines  the  lowest 
allowable  object  classification  laEel  that  nay  be  assigned  to  the  file 
node. 


When  a  file  node  representing  the  device  is  opened,  the  device  inherits 
its  security  classification  label  from  the  process  performing  the  open 
operation.  If  it  is  not  possible  to  label  the  node  representing  the 
device  within  the  bounds  of  the  attributes  HIGHEST_CIASSIFICAnCN  and 
LOWESr_CUSSIFICKnCN ,  the  operation  fails  by  raising  the  exception 
SECURITY  VKXATKW. 


4.4.2. 5  Mandatory  access  dieddng 

When  access  aontrol  is  enforced  for  a  given  operation,  mandatory  access 
control  rules  are  checked.  If  mndatory  access  controls  are  not 
satisfied,  the  operation  terminates  by  raising  the  exception 
SEOURITy_yiOLATIGN,  except  where  the  indication  of  failure  constitutes 
violation  of  mandatory  access  aontrol  rules  for  'read1  operations,  in 
which  case  NMCJBRROR  may  be  raised. 


4.5  Input  and  output 


Ada  input/output  in  [LEM]  Chapter  14  involves  the  transfer  of  data  to 
and  from  Ada  external  files.  CAIS  input /output  usee  the  same 
input/output  model  and  also  involves  the  transfer  of  data  to  and  from 
CAIS  file  nodes.  These  file  nodes  may  represent  disk  or  other  secondary 
storage  files,  nagnstic  tape  drives,  terminals,  or  queues. 
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4.5.1  (MS  file  nodes 

CMS  file  nodes  represent  information  about  and  contain  Ada  external 
files.  The  underlying  model  for  the  contents  of  sudi  a  node  is  that  of 
a  file  of  data  items,  accessible  either  sequentially  or  directly  by  seme 
index.  The  packages  specified  in  this  section  provide  facilities  that 
operate  on  CMS  external  files. 

There  are  four  types  of  CMS  sqparted  Ada  external  files:  secondary 
storage,  queue,  terminal,  and  magnetic  tape. 


4.6  Pragmatics 


4.6.1  Pragmatics  for  (MS  node  model 

Several  private  types  are  defined  as  part  of  the  CAIS  Node  Model.  The 
actual  implementation  of  these  types  say  vary  Iran  one  CMS 
implementation  to  the  next.  Nevertheless,  it  is  important  to  establish 
pertain  miniimxns  for  each  type  to  enhance  portability. 

a.  NAME_STRING  At  least  255  characters  must  be  supported 

in  a  CMS  pathname. 

b.  RELATICNSHIP_KE5f  At  least  20  leading  characters  must  be 

significant  in  a  (relationship)  key. 

c.  AITRIB_NAM2  At  least  20  leading  characters  must  be 

KBLAXIGN_NAME  significant  in  attribute  and  relation  names. 

d.  Tree-height  At  least  10  levels  of  hierarchy  must  be 

supported  for  the  primary  relationships. 

e.  Record  size  nunfcer  At  least  32767  bits  per  record  must  be 

supported. 


f.  Open  node  count 


Each  process  must  be  able  to  have  at  least 
15  nodes  open  simultaneously. 
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4.6.2  Pragnatics  for  CAISJSEQOEOTIAL_IO 

A  conforming  implementation  must  sippart  generic  instantiation  of  this 
package  with  any  (non-limited)  constrained  Ada  type  v*j oee  maxinun  size 
in  hits  (as  defined  by  the  attribute  HJMENT_T¥PE '  SIZE )  is  at  least 
32767.  A  conforming  implementation  must  also  support  instantiation  with 
unconstrained  record  types  which  have  default  constraints  and  a  maxinun 
size  in  bits  of  at  least  32767,  and  may  (but  need  not)  use  variable 
length  elements  to  conserve  space  in  the  external  file. 


4.6.3  Pragmatics  for  CAIS_DIRBCT_IO 

Each  element  of  a  direct-access  file  is  selected  by  an  integer  index  of 
type  COUNT.  A  conforming  inplementation  must  at  least  support  a  range 
of  indices  from  one  to  32767  (215-1). 

A  conforming  implementation  must  support  generic  instantiation  of  this 
package  with  any  (non-limited)  constrained  Ada  type  vftose  maximum  size 
in  bits  (as  defined  by  the  attribute  ELEMa/TJIYPE 1  SIZE )  is  at  least 
32767.  A  conforming  implementation  must  also  support  installation  with 
unconstrained  record  types  which  have  default  constraints  and  a  maximum 
size  in  bits  of  at  least  32767,  and  may  (but  need  not)  use  variable 
length  elements  to  conserve  space  in  the  external  file. 


4.6.4  Pragnatics  for  CAIS_TE5CT_IO 

A  conforming  inplanentation  must  support  files  with  at  least  32767 
recards/lines  in  total  and  at  least  32767  lines  per  page.  A  conforming 
implementation  must  support  at  least  255  columns  per  line. 


PROPOSED  MIL-STD-CAIS 
31  OCT  1984 


E 


5.  DETAILED  REQUIREMENTS 

The  following  detailed  requirements  shall  be  fulfilled  in  a  manner 
consistent  with  the  model  descriptions  given  in  Section  4  of  this 
standard. 

5.1  General  node  management 
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This  section  describes  the  CMS  interfaces  for  the  manipulation  of  nodes 
in  general,  of  relationships  and  of  attributes.  These  interfaces  are 
defined  in  three  packages:  CMS_NODE_DfcriWITCNS  defines  types, 
subtypes,  exceptions,  and  constants  used  throughout  the  CAIS; 
CMS_NODE_MANMEMENT  defines  interfaces  for  the  manipulation  of  nodes  in 
general,  of  relationships  and  of  attributes;  and  CMSj5niaJCTURAL_N0DES 
defines  interfaces  for  the  creation  of  structural  nodes. 

Specialized  interfaces  for  the  manipulation  of  process  and  file  nodes 
and  of  their  relationships  and  attributes  sure  defined  in  Sections  5.2. 
and  5.3.,  respectively. 

To  sinplify  manipulation  by  Ada  programs,  an  Ada  type  N0DE_T5fPE  is 
defined  for  values  that  represent  an  internal  handle  for  a  node 
(referred  to  as  a  "node  handle"  ).  Objects  of  this  type  can  be 
associated  with  a  node  by  means  of  an  OPEN  procedure,  causing  an 
"open  node  handle"  to  be  assigned  to  the  object.  Most  procedures  expect 
either  a  parameter  of  type  NODE_TYPE,  or  a  pathname,  or  a  combination  of 
a  base  node  (specified  by  a  parameter  BASE  of  type  NODE_TYPE)  and  a  path 
element  relative  to  it. 

An  open  node  handle  is  guaranteed  always  to  refer  to  the  same  node, 
regardless  of  any  changes  to  relationships  that  could  cause  pathnames  to 
become  invalid  or  to  refer  to  different  nodes.  This  behavior  is 
referred  to  as  the  "tracking"  of  nodes  by  open  node  handles. 

Access  to  a  node  by  means  of  a  pathname  can  only  be  achieved  if  the 
current  process  has  the  respective  access  rights  to  the  node  as  well  as 
to  any  node  traversed  an  the  path  to  the  node. 

The  key  of  a  node  is  the  relationship  key  of  the  last  element  of  its 
pathname. 
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5.1.1  Package  C^S_NODE_DEFINITICtB  - 

This  package  defines  the  Ada  type  NODEJIYPE.  It  also  defines  certain 
enumeration  and  string  types  and 

exceptions  useful  for  node  manipulations. 

type  NCOEjryFE  is  limited  private; 

type  NODEJCtND  is  (FIIZ,  STRUCTURAL,  PROCESS); 

type  INnSNTjSPBCIFICATICN  is 

(EXISTENCE,  READ,  WRITE,  READ  ATTRIBUTES,  WRrrE_ATTRIBUTES, 
APPEND JflTRIBUIES,  READ_RELATICNSHIPS ,  WRITE ^RELATIONSHIPS, 
APPEND_RELA2TCNSHIPS,  READjXNTENT,  WRITEjXNTENT, 
APPQJDJXNTEOT,  OCNTRQL,  EXECUTE,  EXCLUSIVE_READ, 
EXOJUSIVE_WRITE,  EXCLUSIVEJ^EADJOTRIBUTES, 
BOCIIJSIVEJ«RITEJOTRIBUire ,  EXCLUSIVE  APPEND_ATTRIBUIES, 
EXCLUSIVE_READ_RELA!TICNSHIPS ,  EXCTJUSIVE  WRTn2_RElATICNSHIPS , 
EXOLlJSIVEJ\PPEM3_RELATICNSHIPS ,  EXCUJSIVEJ^EADJOCNTEIJT, 
E30CLUSIVE_WRITE_OCNrENr,  EXCLUSIVE  APPB1D  CEKlSir , 
EXCLUSIVEjXNTRCL) ; 

type  INTENTION  is  array(POSITTVE  range  <>)  of  mTEOT_SPECIFICATION; 

subtype  NAME  STRING  is  STRING; 

subtype  REXA£eCNSHIP_KEY  is  STRING; 

subtype  RELATICNJfcEE  is  STRING; 

subtype  EORM_STRING  is  STRING; 

NCOE_T¥PE  describes  the  type  for  node  handles.  NODEJCEND  is  the 
enumeration  of  the  kinds  of  nodes.  INTENT_SPEXIIFICATICN  describes  the 
usage  of  node  handles  end  is  further  explained  in  Section  5. 1.2.1. 
INTENTION  is  the  type  of  parameter  INTENT  of  CMS  subprograms  OPEN  and 
CHANGE_IOTENT,  as  further  explained  in  Section  5. 1.2.1. 

NAMEJ3TRING,  REXATICNSHIP_KEy,  RELATICN_NAME,  and  EOFM_STRING  are 
subtypes  for  pathnames,  relationship  keys,  and  relation  names,  as  well 
as  for  form  strings  used  for  the  notation  of  aggregates  of  attribute 
values  (c.f.  [LRM]  14).  The  value  of  such  strings  is  subject  to 
certain  syntactic  restrictions  whose  violation  causes  exceptions  to  be 
raised. 

TOP_LEVEL  ;  constant  NAME_STRING  j-  " 'CURRENT JJSER"; 

CURRENTJIXE  :  constant  NAME~STRING  ;«  " '  CURRENT_NCDE"  ; 

CURRENTJPROCESS  s  constant  NAME~STRING  :* 

LWESTKEJf  *  constant  RELMTONSHIP_KEY  s* 

EEFALJLT__RELATICN :  constant  RELATICN_NAME  MDCT"; 

TOPJLEVEL,  CURRENT_NCCE,  and  CURRENT_PRDCESS  are  standard  pathnames  for 
the  current  user's  top-level  node,  current  node,  and  current  process, 
respectively.  LATEST_KEY  and  DEFAULTJREUTICN  are  standard  names  for 
the  latest  key  and  the  default  relation  name,  respectively. 
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SIMUSJSRROR  : 
NAME_ERRDR  : 

USEJERRDR  : 

IAYCOTJSRRQR  * 
LOCK  ERROR  : 

ACCESS J/IOLATICN  : 

nnu»r”viotAnoN  : 

SECURITY  VIOLATION 


exception; 

exception; 

exception; 

exception; 

exception; 

exception; 

exception; 

:  exception; 


SfTATUS_ERROR  is  raised  whenever  the  open  status  of  a  node  handle  does 
not  conform  to  expectations. 

NAME  ERROR  is  raised  whenever  an  attenpt  is  made  to  access  a  node  via  a 
pathname  or  node  handle  while  the  node  does  not  exist,  is  unobtainable, 
discretionary  access  control  constraints  for  knowledge  of  existence  of  a 
node  are  violated,  or  mandatory  access  controls  far  'read1  operations 
are  violated.  This  exception  takes  precedence  over  ACCESS_VKXATICN  and 
SEOJRmj/IOIAriCN  exceptions. 

USE_ERROR  is  raised  whenever  a  restriction  on  the  use  of  an  interface  is 
violated. 

IAXOOT_ERRDR  is  raised  whenever  an  error  is  encountered  with  regard  to 
layouts. 

LOCKJERROR  is  raised  whenever  an  attenpt  is  made  to  modify  or  lock  a 
locked  node. 

AIXESSJ/ICLATIGN  is  raised  whenever  an  operation  is  attenpted  which 
violates  access  right  constraints  other  than  knowledge  of  existence  of 
the  node. 

INTQirjYIGLATICN  is  raised  whenever  an  operation  is  attenpted  on  an  open 
node  handle  which  is  in  violation  of  the  intent  specified  when  the  node 
handle  was  opened.  SEEURTIY_VICLAITCN  is  raised  whenever  an  operation 
is  attenpted  which  violates  'mandatory  access  controls  far  ’write' 
operations. 


5.1.2  Package  CMSJTOCJftNAflEMEOT  - 

This  package  defines  the  general  primitives  for  manipulating,  copying, 
renaming,  and  deleting  nodes  and  their  relationships. 

The  operations  defined  in  this  package  are  applicable  to  all  nodes, 
relationships  and  attributes  except  where  explicitly  stated  otherwise. 
These  operations  do  not  include  the  creation  of  nodes.  The  creation  of 
structural  nodes  is  performed  by  the  CREATE JSJODE  procedures  of  package 
CMS  snUCIURAL_NOD£S  (Section  5.1.5),  the  creation  of  nodes  for 
processes  is  performed  by  INVCKE_PROCESS  and  SPAWNJPROCESS  of 
CMSJPRDCESS  OCNTRCL  (Section  5.2.2),  and  the  creation  of  nodes  for 
files  is  performed  by  the  CREATE  procedures  of  the  input/output  packages 
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(Section  5.3). 

There  are  three  QMS  interfaces  for  manipulating  node  handles;  OPEN 
opens  a  node  handle,  CLOSE  cloees  the  node  handle,  and  CHAN3E_INrENr 
altera  the  specification  of  the  intention  of  node  handle  usage.  These 
interfaces  perform  access  syndircnization  in  accordance  with  an  intent 
specified  by  the  parameter  INTENT. 

These  interfaces  are  central  to  the  general  node  administration,  since 
most  other  interfaces  take  node  handles  as  parameters.  While  such  other 
interfaces  nay  also  bs  provided  in  overloaded  versions,  taking  pathnames 
as  node  identification,  these  overloaded  versions  are  to  be  understood 
as  including  implicit  OPEN  calls  with  appropriate  intent  specification 
and  a  defaulted  TTMEJUMIT  parameter. 

One  or  mare  of  the  intentions  defined  in  Table  V  can  be  expressed  by  the 
INTENT  parameters. 

Table  V  Intents 


EXISTENCES 

The  established  access  right  for  subsequent  operations  is  to 
query  properties  of  the  node  handle  and  existence  of  the  node 
node  only.  Lodks  an  the  node  have  no  delaying  effect. 

READ,  EXCLUSIVE_READ: 

The  OPEN  operation  is  delayed  if  the  node,  its  contents, 

attributes  or  relationships  are  locked  against  reed  operations. 
The  established  access  right  for  subsequent  operations  is  to  read 
node  contents,  attributes  and  relationships.  For  EXCLUSIVE__READ, 
the  node  is  locked  against  all  opens  with  write  intent.  In 
addition,  the  OPEN  operation  is  delayed  if  there  are  open  node 
handles  to  the  node  with  write  intent. 

WRITE,  EXCLUSIVE_WRITEt 

The  OPEN  operation  is  delayed  if  the  node,  its  contents, 

attributes  or  relationships  are  locked  against  write  operations. 
The  established  access  right  for  subsequent  operations  is  to 
write,  create  or  append  to  node  contents,  attributes  and 
relationships.  For  EXCLUSIVE_WKrTE,  the  node  is  locked  against 
all  opens  with  read,  write  or  append  intent.  In  addition,  the 
OPE!  operation  is  delayed  if  there  are  open  node  handles  to  the 
node  with  read,  write  or  append  intent. 

READJ3DNTENTS,  EKXJUSIVEJtEADjXNIQflS t 
The  OPEN  operation  is  delayed  if  the  node  or  its  contents  are 
locked  against  read  operations.  The  established  access  right  for 
subsequent  operations  is  to  read  the  node  contents.  For 
E3CCLUSIVE_REAB  CONTENTS,  the  node  contents  are  locked  against  all 
opens  with  write  intent.  In  addition,  the  OPEN  operation  is 
delayed  if  there  are  open  node  handles  to  the  node  with  intent  to 
write  its  contents. 
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HEJENTEHTS,  EXEIllSIVE_WRITE_OCNnSHrSs 

The  OPEN  operation  is  delayed  if  the  node  or  its  contents  are 
locked  against  write  operations.  The  established  access  right 
for  subsequent  operations  is  to  write  or  append  to  the  node 
contents.  For  EXCLUSIVE J^RITEJXNTENTS ,  the  node  oontents  are 
locked  against  all  opens  with-  read,  write  or  append  intent.  In 
addition,  the  OPEN  operation  is  delayed  if  there  are  open  node 
handles  to  the  node  with  intent  to  read,  write  or  append  its 
oontents. 


PENDjOCNTENTTS,  EXCLUSIVE _APPEND_ODNniNrS: 

The  OPEN  operation  is  ""delayed  if  the  node  or  its  oontents  are 
locked  against  append  operations.  The  established  access  right 
for  subsequent  operations  is  to  append  to  the  node  contents.  For 
EXCLUSIVE_APPE6® JXNITNTS ,  the  node  oontents  are  locked  against 
all  opens  with  append  or  write  intent.  In  addition,  the  OPEN 
operation  is  delayed  if  there  are  open  node  handles  to  the  node 
with  intent  to  append  or  write  its  contents. 


ADJOTRIBUTES,  E!XCLiJSIVE_READ_A3TRIHUTTS : 

The  OPEN  operation  is  delayed  if  the  node  or  its  attributes  are 
locked  against  read  operations.  The  established  access  right  for 
subsequent  operations  is  to  read  node  attributes.  For 
EXCLUSIVE^  HEAD _AlTFRIEUIES,  the  node  is  locked  against  all  opens 
with  intent  to  write  attributes.  In  addition,  the  OPEN  operation 
is  delayed  if  there  are  open  node  handles  to  the  node  with  intent 
to  write  attributes. 


ITTE ’^ATTRIBUTES,  EX(XUSIVE_WRITE_A!ITRIBUraS : 

The  OPEN  operation  is  delayed  if  the  node  or  its  attributes  are 
locked  against  write  operations.  The  established  access  right  for 
subsequent  operations  is  to  modify  and  create  node  attributes. 
For  EXQUSIVE_WRrre _ATntIBUns,  the  node  is  locked  against  all 
opens  with  intent  to  read,  write  or  append  attributes.  In 
addition,  the  OPEN  operation  is  delayed  if  there  are  open  node 
handles  to  the  node  with  intent  to  read,  write  or  append 
attributes. 


PENDJOTRIBUTES,  EXOJUSIVEJVPPENDJOTWBOTESs 

The  OPEN  operation  is  delayed  if  the  node  or  its  attributes  are 
locked  against  append  operations.  The  established  access  right 
for  subsequent  operations  is  to  create  node  attributes.  For 
EXCLUSIVE_APPEND_A1TRIBUIES,  the  node  is  locked  against  all  opens 
with  intent  to  write  or  append  attributes.  In  addition,  the  OPEN 
operation  is  delayed  if  there  are  open  node  handles  to  the  node 
with  intent  to  write  or  append  attributes. 


3\D_RELATT0NSHIPS,  EXCLUSIVE_READ_RELATICNSHIPS : 

The  OPEN  operation  is  delayed  if  the  node  or  its  relationships 
are  locked  against  read  operations.  The  established  access  right 
for  subsequent  operations  is  to  read  node  relationships.  Far 
EXCLUSIVE  READ_RELATICNSHIPS ,  the  node  is  locked  against  all 
opens  witK  intent  to  write  relationships .  In  addition,  the  OPEN 
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operation  is  delayed  if  there  are  open  node  handles  to  the  node 
with  intent  to  write  relationships. 

WRITE_RELAriCNSHIPS ,  EXCLUSIVE_WRITE  RELATICNSHIPS: 

The  OPEN  operation  is  delayed  if- the  node  or  its  relationships 
are  locked  against  write  operations.  The  established  access 
right  for  subsequent  operations  is  to  write  or  create  node 
relationships.  For  EXCLUSIVE  WRnEJ&ATIGNSHXPS,  the  node  is 
locked  against  all  opens  witK  intent  to  read,  write  or  append 
relationships.  In  addition,  the  OPEN  operation  is  delayed  if 
there  are  open  node  handles  to  the  node  with  intent  to  read, 
write,  or  append  relationships. 

APPEND  RELATIONSHIPS,  E<CULJSIVE_APPEND_RELATICNSHIPS : 

The  OPEN  operation  is  delayed  if  the  node  or  its  relationships 
are  locked  against  append  operations.  The  established  access 
ricfat  for  subsequent  operations  is  to  create  node  relationships. 
For  EXCLUSIVE _APPEND_RELATIGNSHIPS,  the  node  is  locked  against 
all  opens  with  intent  to  write  or  append  relationships.  In 
addition,  the  OPEN  operation  is  delayed  if  there  are  open  node 
handles  to  the  node  with  intent  to  write  or  append  relationships. 

CONTROL,  EXCLUSIVE  CONTROL: 

The  OPEN  operation  is  delayed  if  the  node  or  its  relationships 
are  locked  against  write  or  access-control  operations.  The 
established  access  right  for  subsequent  operations  is  to  read  and 
alter  access  control  information.  For  EKLUSIVEjXNrRCL,  the  node 
is  locked  against  all  opens  to  write  node  contents,  attributes  or 
relationships,  or  to  modify  acceas  control  information.  In 
addition,  the  GPB7  operation  is  delayed  if  there  are  open  node 
handles  to  the  node  with  intent  to  write  node  contents, 
attributes  or  relationships,  or  to  read  or  modify  access  control 
information. 


EXECUTE: 

The  OPEN  operation  is  delayed  if  the  node  contents  are  locked 
against  read  operations.  The  established  access  right  far 
subsequent  operations  is  the  permission  to  initiate  a  process 
taking  the  node  contents  as  executable  image. 
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Table  VI.  pr wants  an  overview  of  interfaces  to  query  nodes  and  manipulate 

primary  and  secondary  relationships. 


Table  VI.  Query /Manipulation  Interfaces 


Pathname  queries  The  following  interfaces  allow  certain  queriw 

about  pathnames.  None  of  these  interfaow 
performs  accesses  to  nodes;  they  perform 
pathname  manipulations  at  the  syntactic  level 
only. 

These  interfaces  can  also  be  used  to  establish 
the  syntactic  legality  of  a  pathname. 

function  BASE_PATH 
function  LAST_RELATICN 
function  IAST  KEY 


Node  queries 


The  following  interfaces  allow  pertain  queries 
about  nodes. 


function  OBTAINABLE 
function  IS_SM£ 
procedure  GET_PAREOT 

Node  duplication  The  following  two  interfaces  can  be  used  to 

interfaces  duplicate  single  nodes  or  trees  of  nodes 

spanned  by  primary  relationships. 


procedure  OOPY_NOCE 
procedure  COPTJITOE 

Alteration  of  primary  The  following  interface  can  be  used  to  alter 
relationships  the  primary  relationship  of  a  node,  thereby 

changing  its  unique  primary  name. 

procedure  RENAME 

Deletion  of  primary  The  following  two  interfaces  allow  the 

relationships  deletion  of  the  primary  relationship  of  a 

single  node  or  of  the  primary  relationships 
of  a  node  and  all  the  nodes  that  are 
contained  in  the  tree  spanned  by  primary 
relationships  emanating  fron  these  nodes. 
Removed  of  the  primary  relationship  to  a  node 
makes  the  node  unobtainable.  The  semantics  of 
the  CATS  allow,  but  do  not  force,  individual 
iiqplementations  of  the  CAIS  to  delete  the 
physical  representation  of  unobtainable  nodes. 
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procedure  DCLEIE_NOCE 
procedure  COEIEJIEBS 

Creation  and  deletion 
of  eeoondary 
relationships 

The  following  two  interfaces  allow  the 
creation  and  deletion  of  user-defined 
secondary  relationships. 

procedure  LINK 
procedure  UNLUK 

Node  iterators 

The  following  definitions  and  interfaces  allow 
allow  the  iteration  over  nodes  reachable  from 
a  given  node  via  its  emanating  relationships 
of  the  specified  relation  name  and 
relationship  key  patterns. 

procedure  ITERATE 
function  MOKE 
procedure  GET_NEXT 

Manipulation  of  the 

CURHENT_NOOE 

relationship 

The  following  two  interfaces  allow  changes  of 
the  CURRENT_NOCE  relationship  emanating  from 
the  current  process  node  and  obtaining  an  open 
node  handle  on  the  that  is  the  target  of  the 
CURRENT_NODE  relationship. 

procedure  SET  CURRENT  NOCE 
procedure  GET_current_nqce 

5. 1.2.1  Opening  a  node  handle  - 

procedure  OPEN  (NODE:  in  out  NOCE  TYPE; 

NAM5:  in  NAMfjSTRING; 

INTENT:  in  INTENTION  :*  (BEAD); 

TM  LIMIT:  in  DURATION  :»  DURATION' FIRST ) ; 


procedure  OPEN  (NOCE:  in 

BASE:  in  NOCE  TYPE; 

KEY:  in  RELATIONSHIP  KEY; 

RELATION:  in  RELATICNJtAME  :■ 

CfTAULT_REIATICN ; 

INTENT:  in  INTENTION  :»  (READ); 

•nMEJJMTT:  in  DURATION  :«  DURATION' FIRST); 

Purpose: 

These  procedures  return  an  open  node  handle  in  NODE  to  the  rode 
identified  by  the  pathname  NAtC  or  BASE/KEY/ RELATION ,  respectively. 
The  INTQ7T  parameter  given  determines  the  access  rights  available 
for  subsequent  uses  of  the  node  handle;  it  also  establishes  access 
synchronization  with  other  users  of  the  node.  The  TTMEJLIMTT 
parameter  alios  the  specification  of  a  time  limit 
for  the  delay  imposed  on  OPEN  by  the  existence  of  locks  on  the 


in  out  NOCE  TYPE; 
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node.  A  delayed  OPEN  call  completes  when  the  node  is  unlocked  or 
the  pacified  time  limit  has  elapsed. 

Parameters: 

NCOS  is  a  node  handle,  initially  closed,  to  be  opened  to 

the  identified  node. 

NAME  is  the  pathname  identifying  the  node  to  be  opened. 

BASE  is  an  open  node  handle  to  a  base  node  far 

node  identification. 

KEY  is  the  relationship  key  for  node  identification. 

RELATION  is  the  relation  name  for  node  identification. 

INTENT  is  the  intent  of  subsequent  operations  on  the  node;  the 
actual  parameter  takes  the  form  of  an  array  aggregate. 
TIME_LIMIT  is  a  value  of  type  DURATION,  specifying  a  time  limit 
far  the  delay  on  waiting  far  the  unlocking  of  a  node  in 
accordance  with  the  desired  INUNT. 

Exceptions: 

NAME_ERROR  is  raised  if  any  traversed  node  in  the  path  specified 
by  NAJC  is  syntactically  illegal  or  the  node  specified 
by  BASE  is  unobtainable,  inaccessible  or  non-existent, 
existing,  or  if  the  relationship  specified  by  RELATION 
and  KEY  or  by  the  last  path  element  inplied  by  NAME 
does  not  exist.  NAME_ERHOR  is  also  raised  if  the  node 
to  be  opened  is  inaccessible  or  unobtainable  and  the 
given  INTENT  is  not  (EXISTENCE). 

USEJ2RROR  is  raised  if  the  specified  INTENT  is  an  empty  array. 
STATUS_ERRQR  is  raised  if  the  NODE  is  already  open  prior  to  the 
call  on  OPEN  or  if  the  BASE  is  not  an  open  node  handle. 
LOCK_ERRQR  is  raised  if  the  OPEN  operation  is  delayed  beyond  the 
specified  time  limit  due  to  the  existence  of  lodes  in 
conflict  with  the  specified  INTENT.  This  includes  any 
delays  caused  by  lodes  on  nodes  traversed  on  the  path 
specified  by  the  pathname  NAMS  or  locks  an  the  node 
BASE,  preventing  the  reeding  of  relationships  emanating 
from  these  nodes. 

A(XESS_VIOLATIQN  is  raised  if  the  current  process's  discretionary 
access  control  rights  are  insufficient  to  traverse  the 
path  specified  by  NAME  or  BASE/KEY,  kLXATICN  or  to 
obtain  access  to  the  node  consistent  with  the  specified 
INTENT.  ACCESSJ/ICLATICN  is  raised  only  if  the 
conditions  far  NAff!  ERROR  are  not  present. 
SEXX7RITY_VICIATICN  is  raised  if  the  attempt  to  obtain  access  to  the 
node  specified  by  INTENT  represents  a  violation  of 
mandatory  access  controls  for  the  CAIS. 
SBCURITY^VIOLATICN  is  raised  only  if  the  conditions  for 
other  exceptions  are  not  present. 

Notes: 

An  open  node  handle  acts  as  if  the  handle  forms  an  unnamed  temporary 
secondary  relationship  to  the  node;  this  means  that,  if  the  opened 
node  pointed  to  is  renamed  (potentially  by  another  process),  the 
operations  on  the  opened  node  handle  track  the  renaming. 
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It  is  possible  to  open  a  node  handle  to  an  unobtainable  node  or  to 
an  inaccessible  node.  The  latter  is  consistent  with  the  -foot  that 
the  existence  of  a  relationship  emanating  from  an  accessible  node  to 
which  the  user  has  READ  RELATIONSHIPS  rights  cannot  be  hidden  from 
the  user. 


5. 1.2. 2  Closing  a  node  handle  - 

procedure  ClflSE  (NODE:  in  out  NCCE_TYPE) ; 

Purpose: 

This  procedure  severs  any  association  between  the  node  handle  NODE 
and  the  node  and  releases  any  associated  lock  on  the  node  ixposed 
by  the  intent  of  the  corresponding  OPEN  or  CHANGE_INraNr  operation. 

Closing  an  already  closed  node  handle  has  no  effect. 

Parameter: 

NODE  is  a  node  handle,  initially  open;  to  be  closed. 

Exceptions:  none 

i 

Notes: 

A  NXE_T5fPE  variable  must  be  CLOSBd  before  another  OPEN  can  be 
called  using  the  same  NODE_T¥PE  variable  as  actual  parameter  to  the 
formal  NODE  parameter  of  OPEN. 


5. 1.2. 3  Changing  the  specified  intent  of  node  handle  usage  - 

procedure  CHANQEMNTENT  (NODE:  in  out  N0DE_TXPE? 

INTENT:  in  INTENTION; 

TDC  LIMIT:  in  DURATION  :■  DURATION ’FIRST); 


Purpose:  , 

This  procedure  changes  the  specified  intent  of  usage  of  the  node 
handle  NODE.  It  is  semantically  equivalent  to  closing  the  node 
handle  and  reopening  the  node  handle  to  the  sane  node  with  the 
QRENT  and  TMJ_LIMIT  parameters  of  CHANGE  INTENT,  except  that  i 

CHANGEJQUENT  guarantees  to  return  a  node  hanSle  referring  to  the 
same  node  as  referred  to  prior  to  the  call  (see  , 

the  issue  explained  in  the  note  below). 

Parameter: 

NODE  is  an  open  node  handle 

nmOT  is  a  specification  of  the  usage  intent  as  for  OPEN 

TIMEJLIMrr  is  a  duration  for  the  naximun  delay  of  the  operation 
caused  by  lodes,  as  for  OPEN 

Exceptions: 

NAMMESRQR  is  raised  if  the  node  to  be  opened  is  unobtainable 

_  and  INTENT  is  not  (EXISTENCE) .  j; 

OTNUSJ3WDR  is  raised  if  NODE  is  not  an  open  nods  handle. 
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LOCKJERRDR  is  raised  if  the  qperation  is  delayed  beyond  the 
specified  time  limit  due  to  the  existence  of  lodes  on 
the  node  in  conflict  with  the  specified  INTENT. 

ACCESS_ViaLATICN  is  raised  if  the  the  current  process's 

discretionary  access  control  rights  are  insufficient 
to  obtain  access  to  the  node  consistent  with  the 
specified  by  INTENT.  AOCESS  /IOLATICN  is  raised  only 
if  the  condition  for  NMC^ERTCR  is  not  present. 

SECURITO_VICLATICN  is  raised  if  the  attempt  to  obtain  access  to  the 
node  specified  by  INTENT  represents  a  violation  of 
mandatory  access  controls  for  the  CRTS. 
SECURITY_VIOLAncN  is  raised  only  if  the  conditions  for 
other  exceptions  are  not  present. 


Notes: 

Use  of  the  sequence  of  a  CLOSE  and  an  OPEN  operation  instead  of  a 
CHANGE_lNTENr  operation  cannot  guarantee  that  the  same  node  is 
opened,  since  relationships,  and  therefore  the  node  identification, 
may  have  changed  since  the  previous  OPEN  on  the  node. 


5. 1.2. 4  Examining  open  status  of  node  handle  - 

function  ISJDPEN  (NODE:  in  NOCE  TOPE)  return  BOOLEAN; 


Purpose: 

This  function  returns  TRUE  or  FALSE  according  to  the  open  status 
of  the  node  handle  NOCE. 

Parameter: 

NODE  is  a  node  handle. 

Exceptions:  none 


5. 1.2. 5  Examining  kind  of  node  - 

function  KIND  (NOCE:  in  NODEJTOPE)  return  NOCE__KIND; 

Purpose: 

This  function  returns  the  kind  of  a  node,  either  FILE,  PROCESS, 
STRUCTURAL. 

Parameter: 

NODE  is  an  open  node  handle. 

Exceptions: 

SEASUSJSRROR  is  raised  if  the  node  handle  NODE  is  not  open. 
INTENT_VIOLATICN  is  raised  if  the  node  was  not  opened  with  an 
intent  establishing  the  right  to  read  attributes. 
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5. 1.2.6  Obtaining  unique  primary  name  - 

function  PRIMARY _NAME  (NODE*  in  NQCEJTXPE)  return  NAfCjSTRING; 
Purposes 

This  function  returns  the  unique  primary  name  of  the  node  identified 
by  NODE. 


Parameters 

NODE 

Exceptions: 
NAME  ERROR 


is  an  open  rede  handle  identifying  the  node. 


SEKTUS_ERROR 
LOCK  ERROR 


is  raised  if  any  node  traversed  an  the  primary  path 
to  the  node  is  inaccessible  or  unobtainable, 
is  raised  if  the  node  handle  NODE  is  not  open. 

_  is  raised  if  access  consistent  with  intent 

READJESSATICNBHIPS  to  any  node  traversed  on  the 
prisary  path  cannot  be  Obtained  due  to  an  existing 
lock  an  the  node. 

INTEUTVIGUnCK  is  raised  if  NOCE  was  not  opened  with  an  intent 
”  establishing  the  right  to  read  relationships. 

AXESS_VICLAnCN  is  raised  if  the  current  process's  discretionary 
access  control  rights  are  insufficient  to  traverse 
the  node's  primary  path.  A3CESS_VICLATI0N  is  raised 
only  if  the  conditions  for  NAMJ  ERROR  are  not 


5.1. 2. 7  Obtaining  relationship  key  of  a  primary  relationship  - 

function  PRIMARY  KEY  (NOCE*  in  NOCE  TYPE) 

return  RQATICNSHIP  KEY; 


Purposes 

This  function  returns  the  relationship  key  of  the  last  path  element 
of  the  unique  primary  path  to  the  node. 

Parameter* 

NOCE  is  an  open  node  handle  identifying  the  node. 

Exceptions* 

NAMEJSOGR  is  raised  if  the  parent  node  of  the  node  identified 
_ by  NOCE  is  inaccessible. 

9EKIUSERRQR  is  raised  if  the  node  handle  NOCE  is  not  open. 
LOCKJEHEOR  is  raised  if  the  parent  node  is  locked  against  reading 
relationships. 

IMEDirvi<XAnON  is  raised  if  NODE  wee  not  opened  with  an  intent 

_  establishing  the  right  to  read  relationships. 

ACCESS_yiCCATICN  is  raised  if  the  currant  process's  discretionary 
acceoe  control  rights  are  insufficient  to  obtain 
access  to  the  node's  parent  consistent  with  intent  to 
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READ_RELATIONSKZP.  ACCESSJ/ICLATIGN  is  raised  only  if 
the  conditions  for  NAME_ERROR  are  not  prsssnt. 


5. 1.2. 8  Obtaining  relation  name  of  a  primary  relationship  - 

function  PRIMARY  RELATION  (MODE:  in  NODE  TYPE) 
return-* RELATICN_NAME ; 

Purpose: 

This  function  returns  the  relation  name  of  the  last  path  element  of 
the  unique  primary  path  to  the  node. 


Parameter: 

NODE 


is  an  open  node  handle  identifying  the  node. 


Exceptions: 

NAMEJEKOR  is  raised  if  the  parent  node  of  the  node  identified  by 
NODE  is  inaccessible. 

STATUSJERROR  is  raised  if  the  node  handle  NODE  is  not  open. 

LOCK_ERROR  is  raised  if  the  parent  node  is  locked  against  reading 
relationships. 

INTENT^VICLATICN  is  raised  if  NODE  was  not  opened  with  an  intent 
establishing  the  right  to  read  relationships. 

AGCESS^yiOLATIGN  is  raised  if  the  current  process 'a  discretionary 
~~  access  control  rights  are  insufficient  to  obtain 
access  to  the  node's  parent  consistent  with  intent  to 
READ_RELATIONSHIPS.  ACCESS  VIOLATION  is  raised  cnly  if 
the  conditions  far  NAME_ERROR  are  not  present. 


5. 1.2. 9  Obtaining  relationship  key  of  last  relation  traversed  - 
function  HUSKEY  (NODE:  in  NODEJKPE)  return  REIATICtJSHIP_KEY; 
Purpose: 

This  function  returns  the  relationship  key  of  the  last  path  element 
of  the  path  used  in  opening  this  node  handle. 

Parameter: 

NODE  is  an  open  node  handle. 

Exceptions: 

STATUS  ERROR  is  raised  if  the  node  handle  NODE  is  not  open. 
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5.1.2.10  Obtaining  relation  name  of  last  relation  traversed  - 

function  PATHJHATICN  (NODE:  in  NQGEJHPE)  return  RELATION I_NftME; 
Purposes 

This  function  returns  the  relation  name  of  the  last  path  element  of 
the  path  used  in  opening  this  node  handle. 

Parameter: 

NODE  is  an  open  node  handle. 

Exceptions: 

STC3VHJS_ERRDR  is  raised  if  the  node  handle  NODE  is  not  open. 


5.1.2.11  Obtaining  a  partial  pathname 

function  BASE_PA3H  (NAt®:  NAME_STRING)  return  NAMSJ7FRING; 
Purpose: 

This  function  checks  the  syntactic  legality  of  the  pathname  NAME. 
It  returns  the  pathname  obtained  by  deleting  the  last  path  element 
from  NAJ®.  It  does  not  establish  whether  the  pathname  identifies  an 
existing  node;  only  the  syntactic  properties  of  the  pathname  are 
examined. 

Parameters: 

NAME  is  a  pathname  (not  necessarily  identifying  a  node). 
Exceptions: 

NAME  ERROR  is  raised  if  NAME  is  a  syntactically  illegal  pathname. 


5.1.2.12  Obtaining  the  name  of  the  last  relationship  in  a  pathname 
function  LAST_RELATICN  (NAME:  NATCJSTRINS)  return  RELATION _NAME; 
Purpose: 

This  function  checks  the  syntactic  legality  of  the  pathname  NAME. 
It  returns  the  name  of  the  relation  of  the  last  path  element  of  the 
pathname  NAME.  It  does  not  establish  whether  the  pathname 
identifies  an  existing  node;  only  the  syntactic  properties  of  the 
pathname  are  examined. 

Parameters: 

NAME  is  a  pathname  (not  necessarily  identifying  a  node). 
Exceptions: 

NA*C_ERROR  is  raised  if  NAME  is  a  syntactically  illegal  pathname. 


5.1.2.13  Obtaining  the  key  of  the  last  relationship  in  a  pathname 
function  LAST_KEY  (NAME:  NAMEJ3TRING)  return  REXATICNSHIP_KEY' ; 
Purpose: 

This  function  checks  the  syntactic  legality  of  the  pathname  NAME. 
It  returns  the  relationship  key  of  the  last  path  element  of  the 
pathname  NAME.  It  does  not  establish  vhether  the  pathname 
identifies  an  existing  node;  only  the  syntactic  properties  of  the 
pathname  are  examined. 

Parameters: 

NAME  is  a  pathname  (not  necessarily  identifying  a  node). 
Exceptions: 

NAME  ERROR  is  raised  if  NAME  is  a  syntactical ly  illegal  pathname. 
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5.1.2.14  Querying  existence  of  node 

function  OBTAINABLE  (MODE:  N0DE_TYPE)  return  BOOLEAN; 

Purpose; 

This  function  returns  TRUE  if  the  node  identified  by  NODE  is  not 
unobtainable  and  not  inaccessible.  It  returns  FALSE  otherwise. 

Parameters: 

NODE  is  an  open  node  handle  identifying  the  node. 

Exceptions: 

STATUS_EM®R  is  raised  if  MODE  is  not  an  open  node  handle. 
Additional  Interfaces: 

function  OBTAINABLE  (NAME:  NAME_STRING)  return  BOOLEAN 
is 

NODE:  NODE_TYPE; 

RESULT:  BOOUAN; 
begin 

OPEN  (MODE,  NAME,  (EXISTENCE) ) ; 

RESULT  :»  OBTAINABLE  (NODE) ; 

CLOSE  (NODE) ; 
return  RESULT; 
exception 

when  others  =*>  return  EAIEE; 
end  OBTAINABLE  ; 

function  OBTAINABLE  (BASE:  in  NODE_TYPE; 

KEY:  in  RSAFICNSHIPJCEY; 

RELATION:  in  RnATICN_NAME  :■  EEFAULT_RELATICN ) 

return  BOOLEAN 
is 

NODE:  NOOEJKPE; 

RESULT:  BOOLEAN; 
begin 

OPEN (NODE,  BASE,  KEY,  RELATION,  (EXISTENCE) ) ; 

RESULT  :-  OBTAINABLE  (NODE); 

CLOSE (NODE); 
return  RESULT; 
exception 

when  others  *>  return  FALSE; 
end  OBTAINABLE; 

Notes: 

OBTAINABLE  can  be  used  to  determine  vhether  a  node  identified  via  a 
secondary  relationship  has  been  made  unobtainable  by  a  dpt  .ftp 
qp«ratian  or  is  inaccessible  to  the  current  process  (see  Note  in 
Section  5. 1.2. 1.1). 


PROPOSED  MUr-STD-CAIS 
31  OCT  1964 


5.1.2.15  Querying  sameness 

function  IS_SAI«(NSDE1:  in  NXE  TYPE; 

N0CE2:  in  NOCCJOTB) 
return  BOOLEAN;  ” 

Purpose: 

This  function  returns  true  or  false,  depending  on  whether  the  nodes 
identified  by  its  argunents  are  the  same  node. 


Parameters: 

NCDE1 

N0DE2 


is  an  open  node  handle  to  a  node, 
is  an  open  node  handle  to  a  node. 


Exceptions: 

SEAOTS_ERRDR  is  raised  if  the  node  handles  N0GE1  or  N0CE2  are  not 
“  open. 

Additional  Interface: 

function  IS_SAME(NA*«1:  in  IAMB  STRING; 

NNC2:  in  NMCfjSniING) 
return  BOOUW 
is 

NGGEl,  NOOE2:  NODE  TYPE? 

RESULT:  BOOLEAN; 

begin 

0PEN(NXE1,  NAME1,  (EXISTENCE)); 
begin 

0PQKNCDE2,  NAME2,  (EXISTENCE)); 
exertion 

when  others  =•> 

CLOSE  (N0DE1); 
raise; 

end; 

RESULT  IS  SAME(N0DE1,  N0DE2) ; 

CLOSE(NOOEl); 

CL0SE(NCEE2); 
return  RESULT; 
end  IS_SAME; 

Notes: 


Sameness  is  not  to  be  aenfused  with  equality  of  attribute  values, 
relationships  and  contents  of  nodes,  whidi  is  a  necessary  but  not  a 
sufficient  criterion  for  sameness. 


V 
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5.1.2.16  Obtaining  open  node  handle  to  parent  node 

procedure  GET__PARENT  (PARENT:  in  NODE  TYPE? 

NODE:  in  out  NODETtYPE; 

INTENT:  in  INTENTION  :»  (READ); 

TD«_LIMIT:  in  DURATION  :»  DURATION' FIRST); 

Purpose: 

This  procedure  returns  an  open  node  handle  in  PARENT  to  the  parent 
node  o£  the  node  identified  by  the  open  node  handle  NODE.  The 
intent  under  which  the  node  handle  PARENT  is  opened  is  specified  by 
INTENT.  A  call  on  GETJPARENT  is  equivalent  to  a  call  OPEN  (PARENT, 
NODE,  "",  "PARENT",  (INTENT)). 

Parameters: 

PARENT  is  a  node  handle,  initially  closed,  to  be  opened  to 

the  parent  node. 

NODE  is  an  open  node  handle  identifying  the  node. 

INTENT  is  the  intent  of  subsequent  operations  on  the  node 

handle  PARENT. 

TBC_LIMrr  is  a  value  of  type  DURATION,  specifying  a  time  limit 
far  the  maxiirun  delay  an  waiting  far  the  unlocking  of 
the  node  in  accordance  with  the  specified  intent. 

Exceptions: 

NAME_ERROR  is  raised  if  the  node  identified  by  NODE  is  a 

top-level  node  or  if  its  parent  node  is  inaccessible. 

STATOS_ERROR  is  raised  if  the  node  handle  PARENT  is  open  prior  to 
the  call  or  if  the  node  handle  NODE  is  not  open. 

USE _ERRDR  is  raised  if  INTENT  is  an  aipty  intent 

specification. 

IOCK_ERROR  is  raised  if  the  opening  of  the  parent  node  is 

delayed  beyond  the  specified  TIEE__LJMrr  due  to  the 
existence  of  locks  in  conflict  with  the  specified 
INTENT. 

INIENT_VICLAncN  is  raised  if  NODE  was  not  opened  with  an  intent 
establishing  the  right  to  read  relationships. 

ACCESS_VIOLAnCN  is  raised  if  the  current  process's  discretionary 
access  control  rights  are  insufficient  to  obtain 
access  to  the  parent  node  with  the  specified  INTENT. 

SEX3JRITY_yiOLATICN  is  raised  if  the  attarpt  to  gain  EXISTENCE 
access  to  the  parent  node  represents  a  violation  of 
mandatory  access  controls  for  the  GAIS. 
SBCURTIY_VICIATICN  is  raised  only  if  the  conditions 
for  other  exceptions  are  not  present. 
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5.1.2.17  Copying  a  node 

procedure  COPY  NODE  (FROM:  in  NODE  TYPE; 

TO  BASE:  in  NGCE”TYFE; 

TO“KEYs  in  RELATIONSHIP  KEY; 

TOJRELATICN:  in  REtAnCNJCtf®  :- 

EEFAULTJdATION)  ; 

Purpose: 

This  procedure  copies  a  file  or  structural  node  that  does  not  have 
emanating  primary  relationships.  The  node  copied  in  identified  by 
the  open  node  handle  FROM  and  is  copied  into  a  newly  created  node. 
The  new  node  is  identified  by  the  coitoinaticn  of  the  TO_BASE,  TO_KEY 
and  TO_FELATXCN  parameters.  The  newly  created  node  is  of  the  same 
kind  as  the  node  identified  by  FROM.  If  the  node  is  a  file  node, 
its  contents  are  also  copied,  i.a.,  a  new  copied  file  is  created. 
Any  secondary  relationships  emanating  from  the  original  node, 
excepting  the  PARENT  relationship  (which  is  appropriately  adjusted), 
are  recreated  in  the  copy.  If  the  target  of  the  original  node’s 
relationship  is  the  node  itself,  then  the  aopied  relationship  still 
refers  to  the  same  target  node.  If  the  target  is  the  node  itself, 
then  the  copy  has  an  analogous  relationship  to  itself.  Any  other 
secondary  relationship  vhose  target  is  the  original  node  is 
unaffected.  All  attributes  of  the  FROM  node  are  also  aopied. 
Regardless  of  any  locks  on  the  node  identified  by  FRCM,  the  newly 
created  node  is  unlocked. 

Parameters: 

FRCM  is  an  open  node  handle  to  the  node  to  be  copied. 

TO_BASE  is  an  open  node  handle  to  the  base  node  for 

identification  of  the  node  to  be  created. 

TO_KEY  is  a  relationship  key  for  the  identification  of  the 

node  to  be  created. 

TO_RELATION  is  a  relation  name  for  the  identification  of  the  node 
to  be  created. 

Exceptions: 

NAME__ERROR  is  raised  if  the  new  node  identification  is  illegal 
or  if  a  node  already  exists  with  the  identification 
given  for  the  new  node. 

USEJERRQR  is  raised  if  the  original  node  is  not  a  file  or 
structural  node  or  if  any  primary  relationships 
emanate  from  the  original  node. 

STATUSJERRDR  is  raised  if  the  node  handles  FRCM  and  TO  BASE  are 
not  open.  ~ 

INTEOT_yi<XAnCN  ia  raised  if  FROM  was  not  opened  with  an  intent 
establishing  the  right  to  read  contents,  attributes, 
and  relationships  or  if  TOJBASE  was  not  opened  with 
an  intent  establishing”  the  right  to  append 
relationships.  IOTENIM/ICLAITGN  is  not  raised  if  the 
conditions  for  NA>E  ERROR  are  present. 

SBaJRITY_yiClAnCN  is  raised  Tf  the  operation  represents  a 
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violation  of  mandatory  access  controls  and  the 
conditions  for  other  exceptions  are  not  present. 


Additional  Interface: 

procedure  OOPY  NODE  (FROM:  in  NODETYPE; 

TO:  in  NNeSTRING) 

is 

TO_BASE:  NOOEJIYPE; 
begin 

OPEN (T0J3ASE,  BASE  PATH(TO),  (APPEND  RELATIONSHIPS)); 

OOPY  NODE  (FROM,  TOjaASE,  LAST  KEY(TOT,  WST_RELATICN(TO)); 
CLOSE  (TO_BASE) ;  ~ 

exception 

When  others  *> 

CLOSE (TO  BASE) ; 


end  OOPY  NCDE; 


5.1.2.18  Copying  trees 

procedure  COPY_TREE  (FROM:  in  NOCE_TYPE; 

TO  BASE:  in  NCCE_TYPE; 

TOJCEY:  in  RELATICNSHIP_KEY; 

TO_HELATICN:  in  HELATI(M_NA»« 

E3EFAULT_RELATION )  ? 

Purpose: 

This  procedure  copies  a  tree  of  nodes  formed  by  primary 
relationships  onanating  from  the  node  identified  by  the  node  handle 
FROM.  Primary  relationships  are  recreated  between  corresponding 
copied  nodes.  The  root  node  of  the  newly  created  tree  corresponding 
to  the  FROM  node  is  the  node  identified  by  the  acnfeination  of  the 
TO  BASE,  TO_KEY  and  TO_RELATICN  parameters.  If  an  exception  is 
raised  by  the  procedure,  none  of  the  nodes  are  copied.  Secondary 
relationships,  attributes,  and  node  contents  are  copied  as.  described 
far  OOPY  NODE  with  the  following  additional  rules:  secondary 
relationships  between  two  nodes  vfaich  both  are  copied  are  recreated 
between  the  two  copies.  Secondary  relationships  emanating  from  a 
node  which  is  copied,  but  which  refer  to  nodes  outside  the  tree 
being  aopied,  are  aopied  so  that  they  emanate  from  the  copy,  but 
still  refer  to  the  old  (uneopied)  node.  Secondary  relationships 
emanating  from  a  node  which  is  not  copied,  but  whic±i  refer  to  nodes 
inside  the  tree  being  oopied,  are  unaffected. 


Parameters: 

FROM 

It)  BASE 


TO  KEY 


is  an  open  node  handle  to  the  root  node  of  the  tree  to 
be  oopied. 

is  an  open  node  handle  to  the  base  node  for 
identification  of  the  node  to  be  created  as  root  of  the 
new  tree. 

is  a  relationship  key  for  the  identification  of  the 
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node  to  be  created  as  root  of  the  net*/  tree. 

TO_RELATICN  is  a  relation  name  for  the  identification  of  the  node 
to  be  created  as  root  of  the  new  tree. 

Exceptions: 

NAME_ERROR  is  raised  if  the  ne*i  node  identification  is  illegal  or 
or  if  a  node  already  exists  with  the  identification 
given  for  the  new  node  to  be  created  as  a  copy  of  the 
node  identified  by  FROM. 

STAOTSJERRDR  is  raised  if  the  node  handles  FROM  and  TOJ3ASE  are  not 
open. 

USE_ERROR  is  raised  if  the  original  node  is  not  a  file  or 
structural  node. 

L0CK_ERR0R  is  raised  if  any  node  to  be  copied  is  locked  against 
read  access  to  attributes,  relationships  or  contents. 

INTEOTJViatAnCN  is  raised  if  FROM  is  not  open  with  an  intent 
establishing  the  ri$tt  to  read  node  contents, 
attributes  and  relationships  or  if  TO_BASE  is  not  open 
with  an  intent  establishing  the  right  to  append 
relationships.  INTENr_VICLATICN  is  only  raised  if  the 
conditions  for  NW®_ERHOR  are  not  present. 

AOCESS_VICXAriGN  is  raised  if  the  current  process's  discretionary 
access  control  rights  are  insufficient  to  obtain  access 
to  each  node  to  be  copied  with  intent  READ. 

SBCCJRTIY_VI0LATICN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  controls  and  the 
conditions  for  other  exceptions  are  not  present. 


Additional  Interface: 

procedure  COPY  TREE  (FROM: 

TO: 


in  NOCEJIYPE; 
in  NA«  STRING) 


TO_BASE:  NOOETTPE; 
begin  ” 

CPEN(TOBASE,  BASEJPATH  (TO ) ,  (APPEND  RELATIONSHIPS)); 
COPYJTFEE ( FRCM,  TOJBASE,  LAST  KEJT(toT/  LAST  RELATICN(TO) ) ; 
CLOSE  (TO_BASE)  ?  “ 

exception 

when  others  *> 

CLOSE  (TOJ3ASE ) ; 
raise; 
end  COPY  TREE; 
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5.1.2.19  Renaming  primary  relationship  of  a  node 


procedure  RENAME  (NCOS: 

NEW_BASE: 

NEW_KE3f: 

NEW  RELATION: 


in  NODEJPXPE? 
in  NODEJKPE; 
in  HHAPKMSHIP JOEY  y 
in  RELATICN_NAME  :■ 

DEFAULT  RELATION); 


Purpose: 

This  procedure  renames  a  file  or  structural  node.  It  deletes  the 
primary  relationship  to  the  node  identified  by  NODE  and  installs  a 
new  primary  relationship  to  the  node,  onanating  from  the  node 
identified  by  NEWJ3ASE,  with  key  and  relation  name  given  by  the 
NEW_KEY  and  NEW  RELATION  parameters.  The  parent  relationship  is 
changed  accordingly.  This  effectively  changes  the  unique  primary 
name  of  the  node.  Existing  secondary  relationships  with  the  renamed 
node  as  target  track  the  renaming,  i.e. ,  they  have  the  renamed  node 
as  target. 


Parameters: 

NODE  is  an  open  node  handle  to  the  node  to  be  renamed. 

NEW_BASE  is  an  open  node  handle  to  the  base  node  from  which  the 

the  new  primary  relationship  to  the  renamed  node 
emanates. 

NEW_KEY  is  a  relationship  key  far  the  new  primary 
relationship. 

NEW_RELACTCN  is  a  relation  name  for  the  new  prinary 
relationship. 

Exceptions: 

NAE£_ERROR  is  raised  if  the  new  node  identification  is  illegal  or 
if  a  node  already  exists  with  the  identification  given 
for  the  new  node. 

USE_ERROR  is  raised  if  the  node  identified  by  NODE  is  not  a  file 
or  structural  node  or  if  the  renaming  cannot  be 
accomplished  while  still  maintaining  acircularity  of 
primary  relationships  (e.g. ,  if  the  new  parent  node 
would  be  the  renamed  node). 

STA1US_ESRDR  is  raised  if  the  node  handles  NODE  and  NEWJBASE  sure 
not  open. 

IOTE27r_VICLAnCN  is  raised  if  NODE  was  not  opened  with  an  intent 
establishing  the  right  to  write  relationships  or  if 
NEW_BASE  was  not  opened  with  an  intent  establishing 
_  the  right  to  append  relationships. 

ACCESS_VICtATIGN  is  raised  if  the  current  process  does  not  have 
sufficient  discretionary  access  control  rights  to 
obtain  access  to  the  parent  of  the  node  to  be  renamed 
with  intent  WRirE_RELATICNSHIPS  and  the  conditions  for 
NAMEJERRDR  are  not  present. 

SECURTXY_VIO£AriCN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  controls. 
SBCURITY_yiOLATICN  is  raised  only  if  the  conditions 
for  other  exceptions  are  not  present. 
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Additional  Interfaces 


procedure  RENMC  (NODE: 

MEW  NNCs 


is 


in  MODE  TYPE; 

in  najeTstrins) 


NEW__BASE:  NCOEJTYPE; 
begin 

OPEN  (NEW  BASE,  BASE  PASH  (NEW  NAME),  (APFOD  RELATIONSHIPS)); 
COPY  TREE  (FROM,  N&M BASE,  LAST  KEY  (NEW  NAh«T, 

“  ~  LAST  FnATICtI(NEW_NAME) ) ; 

CLOSE  (NEW_BASE) ; 
exception 


when  others  ■> 

CLOSE  (NEWJBASE) ; 
raise; 
end  RENAM5; 


Notes: 

Open  node  handles  from  existing  processes  track  the  renamed  node. 


5.1.2.20  Deleting  a  node 

procedure  EEL£IE_NOCE(NGOE:  in  out  NODEJTYPE) ; 


Purpose: 

This  procedure  deletes  the  primary  relationship  to  a  node  identified 

by  NODE.  The  node  becomes  unobtainable.  The  node  handle  NODE  is 

closed.  If  the  node  is  a  process  node  and  it  is  not  yet  TERMINATED 

(Section  5.2),  DQJETE_NCCE  aborts  the  process. 

Parameters: 

NGOE  is  an  open  node  handle  to  the  node  which  is  the  target 

of  the  primary  relationship  to  be  deleted. 

Exceptions: 

NAMSJEMROR  is  raised  if  the  parent  node  of  the  node  identified  by 
NODE  is  inaccessible. 

USE_ERRQR  is  raised  if  any  primary  relationships  emanate  from  the 
“  node. 

STNUSJBttOR  is  raised  if  the  node  handle  MODE  is  not  open  prior  to 
the  cell. 

LOCK_BtAOR  is  raised  if  access,  with  intent  WRITE JBELATIONSHIPS, 
to  the  parent  of  the  node  to  be  deleted  cannot  be 
obtained  due  to  an  existing  lock  on  the  node. 

INJEOTjrcoiAreCN  is  raised  if  the  NODE  wee  not  opened  with  an 
intent  including  EXCLUSIVE_WRITE. 

ACCESS  VICLATICN  is  raised  if  the  current  process  does  not  have 
sufficient  discretionary  access  control  rights  to  obtain 
access  to  the  parent  of  the  node  to  be  deleted  with 
intent  VKTE  RELATIONSHIPS  and  the  conditions  for 
for  NAM5JERR0R  are  not  present. 
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SECURTIY_VICLATICN  is  raised  if  the  operation  represents  a 
~  violation  of  mandatory  access  controls. 

SECURTTY_ViaLATICN  is  raised  only  if  the  conditions  for 
other  exceptions  are  not  present. 

Additional  Interface: 

procedure  OElZa  NOOE(NM£;  in  IAMS  STRING) 

is 

NCCE;  NDCejRPE; 
begin 

GPEN(N0CE,  NNC,  (EXCLUSIVE_WRITE) ) ; 

CCLETE_NCCe  (NCCE ) ; 
exception 

vrfien  others  ■> 

CLOSE  (NCCE); 
raise; 

end  DEXJEIE  NCCE; 


Notes; 

The  QQ£TE_NCCE  operations  cannot  be  used  to  delete  more  than  one 
node  in  a  single  operation.  It  is  left  to  an  inplenentation 
decision,  whether  and  when  nodes  whose  primry  relationships  have 
been  broken  are  deleted.  However,  secondary  relationships  to  such 
nodes  must  remain  until  they  are  explicitly  deleted  using  the  UNLINK 
procedures. 


5.1.2.21  Deleting  primary  relationships  of  a  tree 
procedure  DEX£TE_TREZ(NDCEi  in  out  NDCEJTSfPE); 

Purpose; 

This  procedure  effectively  performs  the  DEUBXE_NCCE  operation  for  a 
specified  node  and  recursively  applies  DELE7IE_TREE  to  all  nodes 
whoee  parent  is  the  the  designated  node.  The  order  in  which  the 
deletions  of  primary  relationships  is  performed  is  not  specified. 
If  the  operations  raise  an  exception,  none  of  the  primary 
relationships  is  deleted. 

Parameters: 

NODE  is  an  open  node  handle  to  the  node  at  the  root  of  the 

tree  venose  primary  relationships  are  to  be  deleted. 

Exceptions; 

NNC'BOOR  is  raised  if  the  parent  node  of  the  node  identified 
by  NCCE  or  any  of  the  nodes  to  be  deleted  are 
inaccessible . 

OTA3USJERRDR  is  raised  if  the  node  handle  NCCE  is  not  open  prior  to 
““  the  call. 

LOCXSOCR  is  raised  if  access,  with  intent  WRITE JSXATIONSHIPS , 
to  the  parent  of  the  node  specified  by  NODE  cannot  be 
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obtained  or  if  access,  with  intent  EXQUSIVE_WRITE, 
cannot  be  obtained  to  any  node  whose  unique  primary 
path  traverses  the  node  identified  by  NODE,  due  to  an 
existing  lock  on  the  node. 

IOTENr_VIQLAnCN  is  raised  if  the  NODE  was  not  opened  with  an 
intent  including  EXCLU5IVE_WRnE  intent. 

ACCESS_VICLA!nCN  is  raised  if  the  current  process  does  not  have 
sufficient  discretionary  access  control  rights  to 
obtain  access  to  the  parent  of  the  node  specified  by 
NODE  with  intent  WRITE_REIATTCNSHIPS  or  to  obtain 
access  to  ary  node  to  be  deleted  with  intent 
EXCLUSIVEJWRITE  and  the  conditions  for  NAM3JERR0R  are 
not  present. 

SBCURITYJ/ICLATICN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  controls. 
SECURITY_VIOLATION  is  raised  only  if  the  conditions 
for  other  exceptions  are  not  present. 

Additional  Interface: 

procedure  DELETE_TREE(NAME:  in  NMC_8TRING) 
is  ” 

NODE:  NODEJWPE; 
begin 

OPEN(NCOE,  NAME,  (EXCXIJSIVEJWRITE) ) ; 

EELETE_TREE ( NCDE ) ; 
exception 

when  others  *> 

CLOSE  (NCDE); 
raise; 

end  DELfcrE_TREE; 

Notes: 

This  operation  can  be  used  to  delete  more  than  one  primary 

relationship  in  a  single  operation. 


5.1.2.22  Creating  user-defined  secondary  relationships 


procedure  LINK  (NODE: 

NEW  BASE: 
NEW” KEY: 

NEW~ RELATION: 


in  NCOEJIYPE; 
in  NOOEJKPE; 
in  REZATICNSHIPJCEY’; 
in  RELATION  NAME  :- 

DEFAULT  RELATION) ? 


Purpose: 

This  procedure  creates  a  secondary  relationship  between  two  existing 
nodes.  The  procedure  takes  a  node  handle  NODE  on  the  target  node,  a 
node  handle  NEW_BASE  on  the  source  node,  and  an  explicit  key  NEW_KE5f 
and  relation  name  NEW  RELATION  for  the  relationship  to  be 
established  fran  NEW  BASET  to  NODE. 
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Parameters: 

NODE  is  an  open  node  handle  to  the  node  to  which  the  new 

secondary  relationship  points. 

NEW_BASE  is  an  open  node  handle  to  the  base  node  from  vhicdi 
the  new  secondary  relationship  to  the  node  emanates. 

NEW_KEY  is  a  relationship  key  for  the  new  secondary 

relationship. 

NEW_REIATICN  is  a  relation  name  for  the  new  secondary 
relationship. 

Exceptions: 

NAMEJERRDR  is  raised  if  the  relationship  key  or  the  relation 
name  are  illegal  or  if  a  node  already  exists  with  the 
identification  given  by  NEW_BASE,  NEW_KEY,  and 
NEW_RELATICN. 

STMTJS  SRRDR  is  raised  if  the  node  handles  NODE  or  NEW_BASE  are 
not  open. 

HHQrr_VICXAnCN  is  raised  if  NEW_BASE  was  not  opened  with  an 
intent  establishing  the  right  to  append  relationships. 

SECXJRITCJTCCXAriCK  is  raised  if  the  operation  represents  a 
violation  of  mandatary  access  controls. 
SEXDRTIYJ/ICLATICN  is  raised  only  if  the  conditions 
for  other  exceptions  are  not  present. 


Additional  Interface: 

procedure  LINK  (CLD_NAME:  in  NAME_STRING; 

NEW_NAME:  in  NAME_STRING) 

is 

NODE. 

NEWJBASE:  N0CE_TXPE; 
begin 

OPEN(NOCE,  CLD_NAME,  (EXISTENCE)); 

OPQKNEWJBASE,  BASEJPA3H  (NEW_NAME ) ,  (APP0®5_RELATICNSHIPS ) ) ; 
LINK  (NODE,  NEW_BASE7  LPSTJ3X  (NEW_NAME ) , 

LAST  RELATION  (NEW  NAME)); 

CLOSE  (NEW  BASE) ; 

CLOSE  (NODE) ; 
exception 

when  others  *> 

CLOSE  (NEW  BASE); 

CLOSE  (NODE) ; 
raise; 


end  LIMC; 
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5.1.2.23  Deleting  user-defined  secondary  relationships 


procedure  UNLHK  (BASE*  in  NGCE  TYPE; 

KEY*  in  RELATIONSHIP  KEY; 

RDATICNs  in  REUNION  NAtff  l- 

CQNjUr  RELATION); 


Purpose* 

This  procedure  deletes  a  secondary  relationship  identified  by  the 
BASE,  KEY  and  RHATICN  parameters. 


Parameters* 

BASE  is  an  open  node  handle  to  the  node  fran  which  the 

relationship  emanates  which  is  to  be  deleted. 

KEY  is  the  relationship  key  of  the  relationship  to  be 

deleted. 

RELATION  is  the  relation  name  of  the  relationship  to  be 

deleted. 


Exceptions* 

NAMEJERROR  is  raised  if  the  relationship  identified  by  BASE,  KEY 
and  ROAriSON  does  not  exist. 

USE_ERROR  is  raised  if  the  specified  relationship  is  a  primary 
relationship. 

SEMTJSjnWGR  is  raised  if  the  BASE  is  not  an  open  node  handle. 

INTENT^VIClAriGN  is  raised  if  BASE  wee  not  opened  with  an  intent 

_  ~  establishing  the  right  to  write  relationships. 

SEX3JRTTY_VICLAnCN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  controls. 
SBCUKrrY_yiOLAriGN  is  raised  only  if  the  conditions 
for  other  exceptions  are  not  present. 

Additional  Interface* 


procedure  UNLDK(NMC*  in  NAtCjSTIKQiG) 

is 

BASE*  NOCEJRPE; 
begin 

GPBI(BASE,  BASE_PKTH(NAME),  (WRCTEJttlAnCNSHIPS)); 
UNLHK(BASE,  LAST_KEY(NAMS) ,  LAST  HEMTICN(NAME)  )  ; 

GLOSE(BASE); 

exception 

when  others  »> 

CLOSE  (BASE); 
raise* 
end  UNLINK; 

Notes* 

UNLINK  can  be  used  to  delete  seoondary  relationships  to  nodes  that 
have  become  unobtainable. 
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5.1.2.24  Iteration  types  and  subtypes 
type  NOCe_I'm<ATOR  is  private; 

subtype  RELATIONSHIP  KEY  PMTEFN  is  RELATIONSHIP_KEY; 
subtype  RELATION  NAME  PATTERN  is  RELATICN_NAME; 


These  types  are  used  in  the  following  interfaces  for  iterating  over  a 
set  of  nodes.  REIAnCNSHIP_KEX_PMTEFN  and  RELATION |_NAME_PATIERN  follow 
the  syntax  of  relationship  keys/ relation  names,  except  that  '?'  will 
natch  any  single  character  and  will  match  any  string  of  characters. 
NODEjnERATOR  is  a  private  type  assumed  to  contain  the  bookkeeping 
information  necessary  for  the  implementation  of  the  MORE  and  GET_NEXT 
functions. 


5.1.2.25  creating  an  iterator  over  nodes 

procedure  ITERATE  (ITERATOR:  oul 

NODE:  in 

KIND:  in 

KEY:  in 

RELATION:  in 

PRIMAKY_CNLY :  in 

Purpose: 

This  procedure  establishes  a  node  iterator  ITERATOR  over  the  set  of 
nodes  that  are  the  targets  of  relationships  emanating  fron  a  given 
node  identified  by  NODE  and  matching  the  specified  KEY  and  RELATION 
patterns.  The  nodes  are  returned  in  ASCII  lexicographical  order  by 
relation  name  and  then  by  relationship  key.  Nodes  that  are  of  a 
different  kind  than  the  KIND  specified  are  emitted.  If  FRIMARY_CNLY 
is  true,  then  only  primary  relationships  are  considered  then 
creating  the  iterator. 

Parameters: 

ITERATOR  is  the  node  iterator  returned. 

NODE  is  an  open  node  handle  to  a  node  whose  relationships 

form  the  basis  for  ocnstructing  the  iterator. 

KIND  is  the  kind  of  nodes  selected  by  ITERATE. 

KEY  is  the  pattern  for  the  relationship  keys  of  nodes  on 

Which  the  iterator  is  based. 

RELATION  is  the  pattern  for  the  relation  names  on  which  the 
iterator  is  based. 

PRIMARY_CNLY  is  a  boolean;  if  TRUE,  only  primary  relationships  will 
be  used  in  constructing  the  iterator;  if  FALSE,  all 
relationships  satisfying  the  patterns  will  be  used. 

Exceptions: 

STMUS_ERRDR  is  raised  if  NODE  is  not  an  open  node  handle. 

INIQ?T_yiGLAriCN  is  raised  if  NODE  was  not  opened  with  an  intent 
establishing  the  right  to  read  relationships.  ■ 

SECURITY  VIOLATION  is  raised  if  the  operation  represents  a 


NODEjnERATOR; 

NODE  TYPE; 

NCCEJKIND; 

REXAnCKSHIP_KEY_PATTERN  :» 
RE3ATICN_NAME_PAITERN 
CEFAULTjRELATION; 
BOOLEAN  TRUE); 
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violation  of  mandatory  access  controls. 
SECURITY_ViaLATICN  is  raised  only  if  the  conditions 
for  other  exceptions  are  not  present. 

Additional  Interface: 

procedure  ITERATE  (ITERATOR:  out  NODE  ITERATOR; 

NAME:  in  NAhEjSreiNS; 

KIND:  in  NODE  KIND; 

KEY:  in  FEUflTCNSHIP  KEY  PAT1HW 

RELATION:  in  RELATTCNJJAME  PATTERN  :- 

DEFAULT_RELATICN ; 
PRIMARY_CNLY :  in  BOOLEAN  :-  TRUE) 
is 

NODE:  NODE_TYPE; 
begin 

OPEN  (NODE,  NAME,  (FEAD_RELATICNSHIPS) ) ; 

ITERATE  (ITERATOR,  NODE,  KIND,  KEY,  REXATICN,  PRIMARYJWLY)  ; 
CUOSE(NODE); 
exception 

when  others  »> 

CLOSE  (NODE); 
raise; 

end  ITERATE; 

Notes: 

The  functions  PATH_KEY  and  PATH_RELATICN  may  he  used  to  determine 
the  relationship  Which  caused  the  node  to  be  included  in  the 
iteration.  The  iteration  interfaces  can  be  used  to  determine  (and 
subsequently  delete)  relationships  to  inaccessible  or  unobtainable 
nodes. 


5.1.2.26  Determining  iteration  status 

function  MORE  (ITERATOR:  in  NCCE_ITERATOR) 

return  BOOLEAN; 

Purpose: 

The  function  MORE  returns  TRUE  or  FALSE,  depending  on  whether  all 
nodes  contained  in  the  node  iterator  have  been  retrieved  with  the 
GE7T_NEXT  procedure. 

Parameters: 

ITERATOR  is  a  node  iterator  previously  set  by  the  procedure 
ITERATE. 

Exceptions: 

USE_ERRDR  is  raised  if  the  ITERATOR  has  not  been  previously  set 
by  the  procedure  ITERATE. 
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5.1.2.27  Getting  the  next  node  in  an  iteration 

procedure  GET_NECT  ( ITERATOR:  in  out  NODE_ITERATOR; 

NEXT_NODE:  in  out  NODEJIYFE; 

INTENT:  in  INTENTION  :»  (EXISTENCE); 

TIME_LIMIT:  in  DURATION  DURATION' FIRST) ; 

Purpose: 

The  procedure  GETJSEXT  returns  an  open  node  handle  to  the  next  node 
in  the  parameter  NEXT_NCDE;  the  intent  under  which  the  node  handle 
is  opened  is  specified  by  the  INTENT  parameter.  If  NEXT_NODE  is 
open  prior  to  the  call  to  GET_NEXT,  it  is  closed  prior  to  being 
opened  to  the  next  node.  A  time  limit  can  be  specified  for  the 
maximum  delay  permitted  if  the  node  to  be  opened  is  locked  against 
access  of  the  specified  INTENT. 

Parameters: 

ITERATOR  is  a  node  iterator  previously  set  by  ITERATE. 

NEXT_NODE  is  a  node  handle,  to  be  opened  to  the  next 

node  on  the  ITERATOR. 

INTENT  is  the  intent  of  subsequent  operations  on  the  node 

handle  NEXT_NODE. 

TIMEJLIMIT  is  a  value  of  type  DURATION,  specifying  a  time  limit 
for  the  maximum  delay  on  waiting  for  the  unlocking  of 
the  node  in  accordance  with  the  specified  intent. 

Exceptions: 

USE_ERROR  is  raised  if  the  ITERATOR  has  not  been  previously  set 
by  ITERATE  or  if  the  iterator  is  exhausted,  i.e. ,  MORE 
( ITERATOR )=FALSE  or  if  INTENT  is  an  arpty  array. 

LOCK_ERRDR  is  raised  if  the  opening  of  the  node  is  delayed  beyond 
the  specified  TIME_LIMTT  due  to  the  existence  of  locks 
in  conflict  with  the  specified  INTENT. 

ACCESS_ViaLATICN  is  raised  if  the  current  process's  discretionary 
access  control  privliges  are  insufficient  to  obtain 
access  to  the  parent  node  with  the  specified  INTENT. 


5.1.2.28  Setting  the  CURKENT_NODE  relationship 

procedure  SET_CUKRENT_NODE  ( MODE :  in  NODE__TYPE) ; 

Purpose: 

This  procedure  specifies  the  node  identified  by  NODE  as  the  current 
node.  The  CURRENT_NCDE  relationship  of  the  current  process  is 
changed  accordingly. 

Parameters: 

NODE  is  an  open  node  handle  to  a  node  to  be  the  new  target  of 

the  CURKENT_MOEE  relationship  emanating  from  the  current 
process  node. 

Exceptions: 


T  1 
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STATUS_ERRDR  is  raised  if  the  node  handle  NODE  is  not  open. 

LOCK_ERRDR  is  raised  if  access,  with  intent  WRTIEJRELATICNSHIPS, 
to  the  current  process  node  cannot  be  obtained  due  to  an 
existing  lock  on  the  node. 

AGCE5S_VIQEAnCN  is  raised  if  the  current  process  does  not  have 
sufficient  discretionary  access  control  ricpits  to  obtain 
access  to  the  current  process  node  with  intent 
WRITE_RELATICNSHIPS  and  the  conditions  for  NAME_ERROR 
are  not  present. 

SEX3JRITY_VIQLATICN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  controls. 
SE3CURITY_yXQLAnGN  is  raised  only  if  the  conditions  for 
other  exceptions  are  not  present. 

Additional  Interface: 


ir 


i 


procedure  SET J2URRENT_N0DE  (NAME:  in  NAME_STRING) 
is 

NODE:  NOOE_T¥PE; 
begin 

OPEN(NCDE,  NAME,  (EXISTENCE)); 

SETJ2URREOT_NCDE  (NCOE ) ; 
exception 

When  others  -> 

CLOSE (NODE); 
raise; 

end  SET  CURRENT  NODE; 


« 


t 


5-1.2.29  Getting  an  open  node  handle  to  the  CURREOT_NODE 

procedure  GETJ3JRREOT_NOCE(NODE:  in  out  NODE_TYPE) ; 

Purpose: 

This  procedure  returns  in  NODE  an  open  node  handle  to  the  current 
node  of  the  current  process;  the  node  handle  is  opened  with  intent 
EXISTENCE. 

Parameter: 

NODE  is  a  node  handle,  initially  closed,  to  be  opened  to 

the  current  node. 

Exceptions: 

STATUS_ERRDR  is  raised  if  NODE  is  an  open  node  handle  prior  to  the 
call. 

D3CKJERR0R  is  raised  if  access,  with  intent  READ_RELATICNSHIPS , 

“  to  the  current  process  node  cannot  be  obtained  due  to 

an  existing  lock  on  the  node. 

SEXDRTIYVIOLATICN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  controls. 
SEX3JRITY_VI0LATICN  is  raised  only  if  the  conditions 
other  exceptions  are  not  present. 

Notes: 
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The  call  on  GET  CURRBfT_NOCE  is  equivalent  to 

GPBI(NQCE,  “‘CURREUT  NODE",  (DdSTQJCE) ) . 


5.1.3  Package  OUSJOTRIBUIES 

This  package  supports  the  definition  and  manipulation  of  attributes  for 
nodes  and  relationships.  The  nans  of  an  attribute  follows  the  syntax  of 
an  Ada  identifier.  The  value  of  each  attribute  is  a  list  of  the  format 
defined  fay  the  package  GAISJJSrjJTZXJTIES  (see  Section  5.4). 
Upper/lower  case  distinctions  are  “‘significant  within  the  value  of 
attributes,  but  not  within  the  attribute  nans. 

unless  stated  otherwise,  the  attributes  predefined  fay  the  C3VIS  cannot  be 
created,  deleted  or  modified  by  the  ueer. 

The  operations  defined  for  the  wn<pii*tira  of  attributes  identify  the 
node  to  which  an  attribute  belongs  either  by  pathname  or  open  node 
handle.  They  identify  a  relationship  implicitly  by  the  last  path 
element  of  a  pathname  or  explicitly  by  bees  node,  key  and  relation  name 
identification. 

Any  syntactically  illegal  attribute  name  is  treated  as  the  name  of  a 
non-existing  attribute. 


5. 1.3.1  Creating  node  attributes 

procedure  CREME_MC0E_A1TRIBUIE  ( NCCE :  in  NCCE_TYPE; 

ATTRIBUTE:  in  ATTRIBUTE  NAME; 

VALUE:  in  LIST  TH>eT; 


Purpose: 

This  procedure  creates  an  attribute,  named  by  ATTRIBUTE  of  the  node 
identified  by  the  open  node  handle  NCCE  and  seta  its  initial  value 
to  VALUE. 


Parameters: 

NODE 

ATTRIBUTE 

VALUE 


is  an  open  node  handle  to  a  node  to  receive  the  new 
attribute. 

is  the  name  of  the  attribute. 

is  the  initial  value  of  the  attribute. 


Exceptions: 

USE_ERRQR  is  raised  if  the  node  already  has  an  attribute  of 
the  given  name  or  if  the  attribute  name  given  is 
syntactically  illegal. 

STATUS  ERROR  is  raised  if  the  node  handle  NOCE  is  not  open. 

xnranQ'ICLAnON  is  raised  if  NODE  was  not  opened  with  an  intent 
—  establishing  the  right  to  append  attributes. 

SBCURITY_VICLATICN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  controls. 
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SECURITY  VICSLATICN  is  raised  only  if  the  conditions 
for  other  exertions  are  not  present. 

Additional  Interface: 

procedure  CREATE J05EJVTTRIBUTE  (NA« :  in  NAMEJ3TRING; 

A3TOIBUIE:  in  AITRIBUIE  NANE; 
VALUE:  in  USTTYPeT 

is 

NODE:  NCOETXPE; 
begin 

OPQl(NODE,  NAME,  ( APPQ© JSLATICNSKLPS ) ) ; 

CREATE J*CCEJ\TTRIBUTE ( NODE ,  ATTRIBUTE,  VALUE)? 

CLOSE  ( NOTE) ; 
exception 

vdien  others  =»> 

CLOSE  (NODE); 
raise; 

end  CREATE  NODE  ATTRIBUTE; 


5. 1.3. 2  Creating  path  attributes 

procedure  CKEATE_PATH_ATTRIBUTE  ( BASE:  in  NCOE_TYPE; 

KEY:  in  RELATIOJSHIPJKEY ; 

RELATION:  in  RELATICN_NAME  :« 

DEFAULT  RELATION; 
ATTRIBUTE:  in  ATTRIBUTE  sfiME? 

VALUE:  m  LISTJIYPET; 

Purpose: 

Ibis  procedure  creates  an  attribute  named  by  ATTRIBUTE  of  a 
relationship  and  set  its  initial  value  to  VALUE.  The  relationship 
is  identified  by  the  base  node  identified  by  the  open  node  handle 
BASE,  the  relation  name  RELATION  and  the  relationship  key  KEY. 

Parameters: 

BASE 

KEY 

RELATION 
ATTRIBUTE 
VALUE 

Exceptions: 

NAME_ERRDR  is  raised  if  the  relationship  identified  by  the 
BASE/KEY/RELATICN  parameters  does  not  exist. 

USE_ERRQR  is  raised  if  the  relationship  already  has  an  attribute 
of  the  given  name  or  if  the  attribute  name  given  is 
syntactically  illegal . 

STATUS  ERROR  is  raised  if  the  node  handle  BASE  is  not  open. 
nntNT^yiCLAnCN  is  raised  if  BASE  was  not  opened  with  an  intent 
establishing  the  right  to  write  relationships. 


is  an  open  node  handle  to  the  nods  from  which  the 
relationship  emanates. 

is  the  relationship  key  of  the  affected  relationship, 
is  the  relation  name  of  the  affected  relationship, 
is  the  attribute  name, 
is  the  initial  value  of  the  attribute. 
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SBCURTIY_VICXAnCN  is  raised  if  the  operation  represents  a 
violation  of  mandatary  access  controls. 
SBCURIT5f_VICtAnCN  is  raised  only  if  the  conditions  for 
other  exceptions  are  not  present. 

Additional  Interfaces 

procedure  CREATE  PATH  ATTRIBUTE  (NAME;  in  NAME_STRING; 

ATTRIBUTE:  in  ATTRIBUTE  NAt£; 

VALUE:  in  LIST  THEj 

is 

BASE:  NQDE_TYPE; 
begin 

OPEN  (BASE,  BASEJPAIH(NAte),  (WRITEJSELATICNSHIPS ) )  ; 
CTEATE_PATH_ATTRIBirrE  ( BASE ,  LAST  KEY  (NAME),  LAST_RELATICN(NAME) , 

ATTRIBUTE, “VALUE)  ; 

CLOSE (BASE) ; 
exception 

vftien  others  *> 

CLOSE (BASE); 
raise; 

end  CREATE  PATH  ATTRIBUTE; 


5. 1.3. 3  Deleting  node  attributes 

procedure  DELETEJJXE  ATTRIBUTE  ( NODE :  in  NOCE_TYPE; 

ATTRIBUTE:  in  ATTRIBUTE  NAME); 


Purpoee: 

This  procedure  deletes  an  attribute,  named  by  ATTRIBUTE,  of  the  node 
identified  by  the  open  node  handle  NCCE. 

Parameters: 

1KX3E  is  an  open  node  handle  to  a  node  vAiose  attribute  is  to 

be  deleted. 

ATTRIBUTE  is  the  name  of  the  attribute  to  be  deleted. 

Exceptions: 

USE_ERRDR  is  raised  if  the  node  does  not  have  an  attribute  of  the 
given  name. 

SEATUS_ERROR  is  raised  if  the  node  handle  NODE  is  not  open. 

IOTBTVICCAITCN  is  raised  if  NCCE  was  not  opened  with  an  intent 

_  ~  establishing  the  right  to  writs  attributes. 

SEX3JRITY_VICLATICN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  controls. 
SEXXJRITY_yiCLATICN  is  raised  only  if  the  conditions  for 
other  exceptions  are  not  present. 

Additional  Interface: 


procedure  DELETE  NCCE  ATTRIBUTE  (NAME:  in  NAME  STRING; 
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ATTRIBUTE:  in  ATTRIBUTE  NAME; 
VALUE*  in  LISTTYPET 

is 

NODE*  NODEJTYPE; 
begin 

OPQKNQDE,  NAME,  (WRITE  RELATIONSHIPS)}; 

DELETE  fJCDE  ATTRIBUTE (NOCE,  ATTRIBUTE,  VALUE); 

CLOSE  (NODE )~ 
exception 

When  others  »> 

CLOSE  (NODE); 
raise; 

end  DELETE  NODE  ATTRIBUTE; 


5. 1.3. 4  Deleting  path  attributes 


procedure  DELETE_PA!IH _ATTRIBUIE(BASE:  in  NOOS_TYPE; 

KEY*  in  REMTXOHSHIP  KEY; 

RELATION*  in  REUnCN_NAl£  *» 

EEFAULT  KQATICN; 
ATTRIBUTE*  in  ATTRIBUTE~NA(e) ; 


Purpose: 


This  procedure  deletes  an  attribute,  named  by  ATTRIBUTE,  of  a 
relationship  identified  by  the  base  node  BASE,  the  relation  name 
RELATION  and  the  relationship  key  KEY. 


Parameters: 

BASE 

KEY 

RELATION 

ATTRIBUTE 


is  an  open  node  handle  to  the  node  from  which  the 
relationship  emanates. 

is  the  relationship  key  of  the  affected  relationship, 
is  the  relation  name  of  the  affected  relationship, 
is  the  attribute  name  of  hte  attribute  to  be  deleted. 


Exceptions* 

NAME_ERROR  is  raised  if  the  relationship  ty  the 

_  BASE/KEY/ RELATION  parameters  doss  not  exist. 

USEJERRQR  is  raised  if  the  relationship  does  not  have  an 

attribute  of  the  given  name. 

BTATOS  ERROR  is  raised  if  the  node  handle  BASE  is  not  open. 

INIHenvyiOIATICN  is  raised  if  BASE  was  not  opened  with  an  intent 
establishing  the  right  to  write  relationships. 

SEOJRITY_VICLATICN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  aontxols. 
SECURITY_VICtATICN  is  raised  only  if  the  conditions 
for  other  exceptions  are  not  present. 


Additional  Interface: 


procedure  EELETE_PAIH_ATTRI BUTE  ( NAME :  in  NAME  STRING; 

ATTRIBUTE:  in  ATTRIBUTE  NAME; 
VALUE*  in  LIST  TYPE! 


68 


3-96 


PROPOSED  MIL-SIE-CAIS 
31  OCT  1964 


is 

BASE:  NOOEJIYPE; 
begin 

OPEN (BASE,  BASE  PAIH(NAra),  (WRITE  RELATIONSHIPS)); 

DQEIE JPAffl JflTCIBUIE ( BASE ,  LAST_KEY(NAME) ,  LAST  RELATICN(NA*E)  , 

ATTRIBUTE,  VALUE); 

CLOSE (BASE); 
exception 

when  others  ■> 

CLOSE  (BASE); 
raise; 

end  DELETE  PATH  ATTRIBUTE; 


5. 1.3. 5  Setting  node  attributes 

procedure  SET  JJCDE_A3TRLBLfIE  (NODE:  in  NODE  TYPE; 

ATTRIBUTE:  in  ATTRIBUIE  NAME; 

VALUE:  in  LISTJHFET; 

Purpose; 

This  procedure  sets  the  value  of  the  nods  attribute  named  by 
ATTRIBUTE  to  the  value  given  by  VALUE.  The  nods  is  identified  by  an 
open  node  handle  NODE. 

Parameters: 

NODE 


ATTRIBUTE 
VALUE 

Exceptions: 

USEJEFRQR  is  raised  if  the  nods  has  no  attribute  of  the  given 

SEAnJS_ERROR  is  raised  if  NODE  is  not  an  open  node  handle. 
INTENT_VIQLA3TCN  is  raised  if  NODE  was  not  opened  with  an  intent 
establishing  the  right  to  writs  attributes. 
SEX3JRTFf_yi(XATICN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  controls. 
SECURITY_VlCtAnCN  is  raissd  only  if  the  conditions 
for  other  exceptions  are  not  present. 

Additional  Interface: 

procedure  SET  NODE  ATTRIBUTE  OMC:  in  NAMEJ3TRING; 

'  ATTRIBUTE:  in  ATTRIBUTE  NAME; 

VALUE*  in  LIST  type! 

is 

NODE:  NQDEJIYFE; 
begin 

OPDT(NCDE,  NAME,  (WRITE  ATTRIBUTES) ) ; 

SET  NODE  ATTRIBUIE(NOOE7  ATTRIBUTE,  VALUE); 

clo3e(noEe); 


is  an  open  nods  handle  to  a  node  whose  attribute  named 
by  ATTRIBUTE  is  to  be  set. 
is  the  name  of  the  attribute, 
is  the  new  value  of  the  attribute. 
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exception 

when  others  ■> 
CLOSE  (NODE); 
raise? 

end  SET  NODE  ATTRIBUTE; 


5. 1.3. 6  Setting  path  attributes 

procedure  SET  PATH  ATTRIBUTE ( BASE i  in  NGQEJHR; 

KEY;  in  FttATICMSHIPJCEJf? 

REZATION;  in  REUOTGNJMC  ;- 

DEFAULT  RQATXGN; 
ATTRIBUTE;  in  ATTRIBUTE  tffite; 

VALUE;  in  USTJRPET; 

Purpose; 

This  procedure  sets  a  relationship  attribute  named  by  ATTRIBUTE  to 
the  value  specified  by  VALUE.  The  relationship  is  identified 
explicitly  by  the  BASE  node,  the  relation  name  RELATION  and  the 
relationship  key  KEY. 

Parameters; 

BASE 

KEY 

RELATION 
ATTRIBUTE 
VALUE 

Exceptions: 

NAtCJERROR  is  raised  if  the  relationship  identified  by  the 
BASE/KEY/ROATICN  parameters  does  not  exist. 

USE_ENHOR  is  raised  if  the  node  does  not  have  an  attribute  of  the 
given  name. 

SEAOTSJEKOR  is  raised  if  the  node  handle  BASE  is  not  open. 

INTENT J/IOLATICN  is  raised  if  BASE  wee  not  opened  with  an  intent 
establishing  the  right  to  write  relationships. 
SECURTnr_VIGUVTICN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  controls. 
SBCURIT5fViaCAncN  is  raised  only  if  the  conditions  for 
other  exceptions  are  not  present. 

Additional  Interface; 

procedure  SET  PAm_ATTRIBUTE ( NAME :  in  NA 1C  STRING; 

ATTRIBUTE;  in  ATTRIBUTE  NAM!; 

VALUE;  in  LISrjIYPET 

is  ~ 

BASE:  NODEJTYPE; 
begin 

OPEN  (BASE,  BASE_PATH  (NAME ) ,  (WRITE_RELATICNSHIPS ) ) ; 

SET  PATH  ATTRIBUTE(BASE,  LAST  KEY(NAfC),  LAST  RELATION  (NAME) , 


is  an  open  node  handle  to  the  node  from  whidi  the 
relationship  enanates. 

is  the  relationship  key  of  the  affected  relationship, 
is  the  relation  name  of  the  affected  relationship, 
is  the  name  of  the  attribute, 
is  the  new  value  of  the  attribute. 
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ATTRIBUTE,  VALUE); 

CLOSE(BASE); 

exception 

When  others  ■> 

CLOSE (BASE) ; 
raise; 

end  SET  PATH  ATTRIBUTE; 


5. 1.3. 7  Getting  node  attributes 

procedure  GET JKXJE JflTRIBUIE  ( NCCE  :  in  NODEJIYPE; 

ATTRIBUTE:  in  MTRIBUTEJIAME; 

VALUE:  in  out  LISTTXPE) ; 

Purpose: 

This  procedure  assigns  the  value  of  the  node  attribute  named  by 
ATTRIBUTE  to  the  parameter  VALUE.  The  node  is  identified  by  open 
node  handle  NODE. 

Parameters: 

MODE  is  an  open  node  handle  to  a  node  vdiose  attribute 

ATTRIBUTE  is  to  be  retrieved. 

ATTRIBUTE  is  the  name  of  the  attribute. 

VALUE  is  the  result  parameter  containing  the  value  of  the 

attribute. 

Exceptions: 

USEJERROR  is  raised  if  the  node  has  no  attribute  of  name 
ATTRIBUTE. 

STATUS_ERROR  is  raised  if  NODE  is  not  an  open  node  handle. 
INTTNT_VIOLATICN  is  raised  if  NODE  was  not  opened  with  an  intent 
establishing  the  ri^it  to  read  attributes. 

Additional  Interface: 

procedure  GET_MXE_ATTRIBUTE  ( NAfE :  in  NAME_OTRING; 

ATTRIBUTE:  in  ATTRIBUTE  NAME; 

VALUE:  in  LIST  TYFeT 

is 

NODE:  NCCE_TYFE; 
begin 

QPEN(NODE,  NAME,  (READ  RELATIONSHIPS)); 

GET_NXE_ATTRIBUIE (NODE,  ATTRIBUTE,  VALUE); 

CI£6E(N0DE); 

exception 

when  others  ■> 

CLOSE  (NODE); 
raise; 

end  GET  NODE  ATTRIBUTE; 
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5. 1.3. 8  Getting  path  attributes 

procedure  GET  PATH_ATTRIBUrE ( BASE :  in  NOCB_TYFE; 

KEY:  in  REATICNSHIP  KEY; 

RELATIONS  in  RELATICN_NM€’  :« 

ISAULTJS1ATI0N; 
ATTRIBUTE:  in  ATIRIBUIE_NA>e; 

VALUE:  in  out  LISTTYPE); 

Purpose: 

This  procedure  assigns  the  value  of  the  relationship  attribute  named 
by  ATTRIBUTE  to  the  parameter  VALUE.  The  relationship  is  identified 
explicitly  by  the  BASE  node,  the  relation  name  RELATION  and  the 
relationship  key  KEY. 

Parameters: 

BASE  is  an  open  node  handle  to  the  node  from  which  the 

relationship  emanates. 

KEY  is  the  relationship  key  of  the  accessed  relationship. 

RELATION  is  the  relation  name  of  the  accessed  relationship. 
ATTRIBUTE  is  the  name  of  the  attribute. 

VALUE  is  the  result  parameter  containing  the  value  of  the 

attribute. 

Exceptions: 

NAMEJERROR  is  raised  if  the  relationship  identified  by  the 

BASE/KEY/ RELATION  parameters  does  not  exist. 

USE_ERROR  is  raised  if  the  relationship  does  not  have  an 

attribute  of  the  given  name. 

S7TATUS_ERROR  is  raised  if  the  node  handle  BASE  is  not  open. 
IOTEOTVIGIATICN  is  raised  if  BASE  was  not  opened  with  an  intent 
establishing  the  right  to  read  relationships. 

Additional  Interface: 

procedure  GCT_PAaH_ATTRIBUTE(NAME:  in  NAME_STRING; 

ATTRIBUTE:  in  ATTRIBUIE  NAME; 

VALUE:  in  LIST  TYPE! 

is 

BASE:  N0DE_TYPE; 
begin 

OPEN(BASE,  BASE _PAIH (NAME),  (READ  RELATIONSHIPS)); 
GE7T_PATH_ATTRIBUTE  ( BASE ,  LAST_KEYXnAME)  ,  LAST_RELATICN  (  NAME ) , 

ATTRIBUTE,  VALUE); 

CLOSE (BASE); 
exception 

when  others  ■> 

CLOSE ( BASE ) ; 
raise; 

end  GET  PATH  ATTRIBUIE; 
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5. 1.3. 9  Attribute  iteration  types  and  subtypes 

subtype  ATTRIBUIE_NAME  is  STRING; 
type  ATITUBLFIE_riERATOR  is  private; 
subtype  ATTRIE(JIE_PAnERN  is  SIRING; 

These  types  are  used  in  the  following  interfaces  for  iteration  over  a 
set  of  attributes  of  nodes  or  relationships.  ATTRIBUTE  NAME  is  a 
subtype  for  the  names  of  attributes.  An  A1TRIBUIEJPATIERN  Has  the  same 
syntax  as  an  ATTRIBUTE_NAME,  except  that  *?'  will  rate*  any  single 
character  and  '*'  will  match  any  string  of  characters. 
AITRIBUIE  ITERATOR  is  a  private  type  assured  to  contain  the  bookkeeping 
information  necessary  for  the  implementation  of  the  MORE  and  GET_NE3CT 
functions. 


5.1.3.10  Creating  iterators  over  node  attributes 

procedure  NOCE_ATTKEBUEB  ITERATE  (ITERATOR:  in  out  ATIRIBLnE_ITERA!rOR; 

NODE:  in  NODE  TYPE; 

PATTERN:  in  ATTR&UTE_PATTEFN:-M*H )  ; 

Purpose: 

The  procedure  NODE _ATTRIBUIE_ITERATE  returns  in  the  parameter 
ITERATOR  an  attribute  iterator  according  to  the  semantic  rules  for 
attribute  selection  given  in  Section  5.1.3. 

Parameters: 

ITERATOR  is  a  result  parameter  containing  the  iterator  to  be 

constructed. 

NOCE  is  an  open  node  handle  to  a  node  over  whose 

attributes  the  iterator  is  to  be  constructed. 
PATTERN  is  a  pattern  for  attribute  names  as  described  in 

Section  5.1.3  and  5. 1.3. 9. 

Exceptions s 

STATUS_BlROR  is  raised  if  NODE  is  not  an  open  node  handle. 

USEJERROR  is  raised  if  the  PATTERN  is  syntactically  illegal. 

INTB?T_VICLAnCN  is  raised  if  NODE  is  not  open  with  an  intent 
establishing  the  right  to  read  attributes. 

Additional  Interface: 

procedure  NXE_ATIRIBLTIE_ITERATE  ( ITERATOR :  in  out  ATTRIBUTE_ITERATOR ; 

NAJC:  in  NAME  STRING; 

PATTER?:,  in  ATTRIBUTE  PATTERN:-"*”) 

is 

NODE:  NODE  TYPE; 
begin 

OPEN  (NODE,  NAME,  (READ  ATTRIBUTES));  _ 

NODE  ATTRIBUTE  ITERATETiTERATC®,  NODE,  PATTERN); 

CLOSE(NCOE); 

exception 

when  others  -> 
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CLOSE (NODE) ? 
raise; 

end  NODE_ATTRIBUrE_ITERATE; 

Notes: 

By  using  the  pattern  **',  it  is  possible  to  iterate  throu^i  the 
names  of  all  attributes  of  a  node. 


5.1.3.11  Determining  iteration  status 

function  MORE  (ITERATOR:  in  ATTRIBUTE  ITERATOR) 

return  BOOLEAN; 


Purpose: 

The  function  MORE  returns  true  or  false  depending  on  whether  all 
attributes  contained  in  the  attribute  iterator  have  been  retrieved 
with  the  procedure  GET_NEXT. 

Parameters: 

ITERATOR  is  an  attribute  iterator  previously  constructed. 

Exceptions:  _ 

USEJERRDR  is  raised  if  the  ITERATOR  has  not  been  previously 

set  by  the  procedures  NOre_ATIRIBUIE_ITERAaE  or 
PMH  ATTRIBUTE  ITERATE. 


5.1.3.12  Getting  the  next  node  attribute 

procedure  GETJ SECT  ( ITERATOR:  in  out  ArrRIBUTE_ITERATOR; 

ATTRIBUTE:  out  ATTRIBUTE  NAfE; 

VALUE  :  in  out  LIST_TYPET ; 

Purpose: 

The  procedure  GET_NEXT  returns,  in  its  parameters  ATTRIBUTE  and 
VALUE,  both  the  name  and  the  value  of  the  next  attribute  in  the 
iterator. 

Parameters: 

ITERATOR 
ATTRIBUTE 

VALUE 


Exceptions: 
USE  ERROR 


is  an  attribute  iterator  previously  constructed, 
is  a  result  parameter  containing  the  name  of  an 
attribute. 

is  a  result  parameter  containing  the  value  of  the 
attribute  named  by  ATTRIBUTE. 


is  raised  if  the  ITERATOR  has  not  been  previously 
set  by  the  procedures  NOCE_ATTRIBUIE_rTERATE  or 
PA!ffl__ATrRIBUIE_ITERATE  or  if  the  iterator  is 
exhausted,  i.e.,  MORE ( ITERATOR )*  false. 
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5.1.3.13  Obtaining  an  iterator  over  relationship  attributes 


procedure  PATH_AIITRIBl7rE_ITERATE  ( ITERATOR: 

BASE: 

REST: 

RELATION: 

PATTERN: 


in  out  A3TRI  BL7TE_ITERATOR ; 
in  NODEJWPE; 
in  RELATICNSHIP_KEY ; 
in  RELATICN_NAME  :» 

DEFAULT_RELATICN  ; 
in  ATTRIBUTE  PATTERN:-"*" ) ; 


Purpose: 

This  procedure  is  provided  to  obtain  an  attribute  iterator  for 
relationship  attributes.  The  relationship  is  identified  explicitly 
by  the  BASE  node,  the  relation  name  RELATION  and  the  relationship 
key  KEY.  The  procedure  returns  an  attribute  iterator  in  ITERATOR 
according  to  the  semantic  rules  for  attribute  selection  applied  to 
the  attributes  of  the  identified  relationship.  This  iterator  can 
then  be  processed  by  means  of  the  MORE  and  GET  NEXT  interfaces. 


Parameters: 

ITERATOR 

NODE 

PATTERN 


is  a  result  parameter  containing  the  iterator  to  be 
constructed. 

is  an  qpen  node  handle  to  a  node  over  whose  attributes 
the  iterator  is  to  be  constructed. 

is  a  pattern  far  attribute  names  as  described  in 
Section  5.1.3  and  5. 1.3. 9. 


Exceptions: 

NAME_ERRDR  is  raised  if  the  relationship  identified  by  the 
BASE/KEY/ RELATION  parameters  does  not  exist. 

USE_ERROR  is  raised  if  the  PATTERN  is  syntactically  illegal. 
STATUS_ERROR  is  raised  if  BASE  is  not  an  open  node  handle. 
INDENIM/IGCATIGN  is  raised  if  BASE  was  not  opened  with  an  intent 
establishing  the  right  to  read  relationships. 


Additional  Interface: 


procedure  PATO_ATTRIBUIE_riERATE  ( ITERATOR:  in  out  ATTRIBUTE_rrERATOR; 

NAME:  in  NAME_STRING; 

PATTERN:  in  ATTRIBtTIEJPAinERN:*"*"); 
is  ““ 

BASE:  NCDEJTCPE; 
begin 

OPQKBASE,  BASE_PATH (NAME ) ,  (WRITE JETATIONSHIPS ) ) ; 
PATH_ATTEIBUTE_riERATE  ( ITERATOR,  BASE,  LAST_KEY(NAME) , 

LAST  RELATION  (NAME),  PATTERN); 

CLOSE (BASE); 
exception 

when  others  »> 

CLOSE(BASE); 

raise; 

end  PATH  ATTRIBUTE  ITERATE; 
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5.1.4  Package  CAISJ^CCESSJCCNTROL 

This  package  provides  primitives  for  manipulating  discretionary  access 
control  information  for  CAIS  nodes.  In  addition,  certain  GAIS 
subprograms  declared  el  severe  allow  the  specification  of  initial  access 
oontrol  information. 


5. 1.4.1  Types,  subtypes,  constants,  and  exceptions 

subtype  PRIVILEGE_SPECIFICATICN  is  SIRING; 

A  privilege  specification  is  a  character  string  in  the  syntax  described 
in  Table  V. 


5. 1.4. 2  Setting  access  oontrol 

procedure  SET JKX3SS JCCNIRCL  ( NODE :  in  NCCE_TYPE; 

RCL£_NODE:  in  NODEJRPE; 

GRANT:  in  PRIVnjBGEjSPBOTia^TICN)  ; 

Purpose: 

This  procedure  sets  access  oontrol  information  for  a  given  node.  If 
one  does  not  exist,  a  secondary  ACCESS  relationship  is  created  from 
the  node  specified  by  NODE  to  the  node  specified  by  RCX£_NODE.  If 
necessary,  the  attribute  GRANT  is  created  on  this  relationship.  The 
value  of  the  GRANT  attribute  is  set  to  the  proper  form  (see  Table  V) 
of  the  privilege  specification  GRANT.  The  effect  is  to  grant  the 
access  specified  by  <2tANT  to  processes  that  have  adopted  the  role 
RCLE_NODE. 

Parameters: 

NODE  is  a  node  handle  to  the  node  vhose  access  control 

information  is  to  be  set. 

RCLE_NODE  is  a  node  handle  to  the  role. 

GRANT  is  a  privilege  specification  describing  what 

privileges  are  to  be  granted. 

Exceptions: 

USE_ERROR  is  raised  if  GRANT  is  not  in  valid  syntax. 

STATUSJERHDR  is  raised  if  NCEE  or  ROLE_NOCE  is  not  open. 
IOTENT_VIQLATICN  is  raised  if  NCCE  was  not  opened  with  intent 
aCNTRQL. 

SECURnY_yiQLATICN  is  raised  if  the  operation  represents  a 
~  violation  of  mandatory  access  controls. 

SEXSJRITYVIGLATIGN  is  raised  only  if  the  conditions 
for  other  exceptions  are  not  present. 

Additional  Interface: 

procedure  SET_ACCESSJXNTRCL  (NAME:  in  NAME  STRING; 

RXE  NAME:  in  NAME” STRING; 
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GRAMTs  in  PRIVIIECEJ5PBCIFICATION) ; 
is 

NODE,  RCLEJJODE:  NODE_TYPE; 
begin 

OPEN  (NODE,  NAME  ( EXISTENCE ) } ; 

OPEN ( RCLE_NCDE ,  ROLE  NAME,  (EXISTENCE) ) ; 

SETJKXESS  CONTROL  (NODE,  ROLE  NODE,  GRANT) ; 

close  (ncdeT; 

CLOSE  ( ROUE JJODE )  ; 
exception 

when  others  =»> 

CLOSE  (NODE) ; 

CLOSE (ROLE_NDCE ) ; 
raise; 

end  SETT  ACCESS  CONTROL; 


5. 1.4. 3  Indicating  access  mode 

function  IS_GRANTED  (OBJECT_NOCE:  in  NODE  TYPE; 

PR3VHEGE_NAME:  in  NAJ«~STRING)  return  BOOLEAN; 
Purpose:  ™ 

This  function  indicates  whether  or  not  a  specific  right  to  a  node  is 
granted  for  the  caller.  If  the  caller  lias  adopted  a  role  that  is 
the  target  of  an  access  relationship  emanating  from  the  abject  node 
and  if  that  relationship's  GRANT  attribute  allows  the  access  right 
specified  by  PRIVIL0OE_NAME,  the  function  returns  TRUE. 

Parameters: 

OBJECT _N0DE  is  a  node  handle  to  the  object  node. 

PRIVIIJB3E_NAf€!  is  a  privilege  name 

Exceptions: 

USEJERROR  is  raised  if  PRIVTLSGEJSAME  is  not  in  valid  syntax. 

STATUS_ERROR  is  raised  if  OBJECT_NOCE  is  not  open. 

IOTENr_yiCLATICN  is  raised  if  NODE  was  not  opened  with  an  intent 
_  establishing  the  right  to  read  relationships. 

SBCURITY_VICLATICN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  controls 
SBCURITY_yiCLAinCN  is  raised  only  if  the  conditions 
for  other  exceptions  are  not  present. 

Additional  Interface 

function  IS_(3*AOTED  (OBJECT_NAME:  in  NAME  STRING; 

PRIVILEGE:  in  NAiCjSTRING)  return  BOOLEAN 

is 

OBJECTJJODE:  NODEJTYPE; 

RESULT:  BOOLEAN; 

begin 

OPEN  (OBJECTJJODE ,  OBJECT  NAME,  (READ  RELATIONSHIPS)); 

RESULT  :■  ISJ3RAOTHD(CBJSCT_NCDE,  PRIVILEGE); 

CLOSE  (OBJECT  NODE); 
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exception 

when  cithers  *> 

CLOSE  (OBJECT _NODE ) ; 
raise; 

end  IS  GRANTEE; 


5. 1.4.4  Adopting  a  group 

procedure  ADOPT  (RCLE_NODE:  in  NOD£_TYPE); 

Purpose: 

This  procedure  causes  the  calling  process  to  adopt  the  group 
specified  by  the  RDUEJJCDE.  A  relationship  of  the  predefined 
relation  ADOPTEE_RXE  is  created  from  the  calling  process  node  to 
the  given  group.  “in  order  for  the  current  process  to  adept  the 
group,  sane  other  role  the  current  process  has  already  adopted  must 
be  a  potential  member  of  the  group  to  be  adapted. 

Parameters: 

BXE_NODE  is  an  open  node  handle  to  a  group  node. 

Exceptions: 

USE_ERR0R  is  raised  if  their  is  no  adopted  role  of  the  current 
process  that  is  a  potential  member  of  the  group 
ROI£_NODE. 

STATOS_ERROR  is  raised  if  RCLE_NCCE  is  not  an  open  node  handle. 

INTE»r_VIOLATICN  is  raised  if  ~RCC£_NGDE  was  not  opened  with  an 
intent  establishing  the  right  to  read  relationships. 

SEXXJRTTY_ViaLATICN  is  raised  if  the  operation  represents  a 
violation  of  mandatory  access  controls. 
SEaJRnY_yiCLKSlCS  is  raised  only  if  the  conditions 
for  other  exceptions  are  not  present. 


5.1.5  Package  CAIS  STRUCTURAL  NODES 

Structural  nodes  are  special  nodes  in  the  sense  that  they  do  not  ha 
contents  as  the  other  nodes  of  the  CAIS  model  do.  Their  purpose 
solely  to  be  carriers  of  earner  information  about  other  nodes  related 
the  structural  node.  Structural  nodes  are  typically  used  to  crea 
conventional  directories,  configuration  objects,  etc. 

The  package  CAIS  J7TFUCIURAL_NOOES  defines  the  primitive  operations  far 
creating  structural*  nodes. 


SC'S 
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5. 1.5.1  Creating  structural  nodes 

procedure  CREA!IE_NODE(NODE:  in  out  NODE_TYPE; 

BASE:  in  NODE  TYPE; 

KEY:  in  RELATIONSHIP  KEY  :- 

LATEST_KEY; 

RELATION:  in  RELATION  NAME 

EEEAULT_RELATICN; 

ATTRIBUTES:  in  LISTJKPE  :*  EMPTY_LIST; 

ACCESSjXNrRDL:  in  FOFM_STRING  :» 

LEVEL:  in  PORMJ5TRING  :* 

Purpose: 

This  procedure  creates  a  structural  node  and  installs  the  primary 
relationship  to  it.  The  relation  name  and  key  of  the  primary 
relationship  to  the  node  and  the  base  node  frog  vriiich  it  emanates 
are  given  by  the  parameters  RELATION,  KEY,  and  BASE.  An  open  node 
handle  to  the  newly  created  node  with  WRITE  intent  is  returned. 

The  ATTRIBUTES  parameter  defines  and  provides  initial  values  far 
attributes  of  the  node  (for  the  use  of  values  of  type  LIST_TYPE,  see 
Section  5.4  CAISJJSTJJTILITIES).  The  ACCESSJXNTRCL  parameter 
specifies  initial  access  control  information  to  be  established  for 
the  created  node. 

The  LEVEL  parameter  specifies  the  security  level  at  which  the  node 
is  to  be  created. 

Parameters: 

NODE  is  a  node  handle,  initially  closed,  to  be  opened  to  the 

newly  created  node. 

BASE  is  an  open  node  handle  to  the  node  from  which  the 

primary  relationship  to  the  new  node  is  to  emanate. 

KEY  is  the  relationship  key  of  the  primary  relationship  to 

be  created. 

RELATION  is  the  relation  name  of  the  primary  relationship  to  be 
created. 

ATTRIBUTES  is  initial  values  for  attributes  of  the  newly  created 
node. 

ACCESSJXNTRCL  is  the  initial  access  control  information  associated 
with  the  created  node. 

LEVEL  is  the  classification  label  for  the  created  node. 

Exceptions: 

NAME_ERRDR  is  raised  if  a  node  already  exists  for  the  node 
identification  given,  if  the  node  identification  is 
illegal,  or  if  any  gro^>  nods  specified  in  the  given 
ACCESSJXNTRCL  parameter  is  unobtainable. 

USEJEBROR  is  raised  if  the  ACCESSJXNTRCL  or  LEVEL  parameters  do 
does  not  adhere  to  the  required  syntax  or  if  the 
ATTRIBUTES  parameter  contains  references  to  predefined 
attributes  not  modifiable  by  the  user. 

STATOS_ERRDR  is  raised  if  BASE  is  not  an  open  node  handle  or  if 
NCCE  is  an  open  nods  handle  prior  to  the  call. 
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INTEOTJVIOLATION  is  raised  if  BASE  was  not  opened  with  an  intent 
establishing  the  right  to  append  relationships. 
SBCURTIYJVICIATICN  is  raised  if  the  operation  represents  a 
violation  of  mandatary  access  controls. 
SECURITY_yiQLATION  is  raised  only  if  the  conditions  for 
other  exceptions  are  not  present. 

Additional  Interfaces: 

procedure  CREATE_NDDE (NODE :  in  out  NOCE_TYPE; 

NAJ®:  in  NAMEJ3TRING; 

ATTRIBUTES:  in  LIST_TYPE  :-  EMPTY__LIST; 

ACCESS JXNTRCL:  in  FORM  STRING  :*  MH; 
LEVEL:  in  FORM_STRING  7*  MN); 

is 

BASE:  NCDEJTYPE; 
begin 

0PE2KBASE,  BASE_PMH(NAME),  (APPEND  RELATIONSHIPS)); 

CREATE  NODE  (NODE/  BASE,  LAST_KEY  (NAME ) ,  LAST  RELATION  (NAME ) , 
ATTRIBUTES,  ACCESS  CONTROL,  LEVEL)? 

CLOSE (BASE); 
exception 

when  others  *> 

CLOSE  (NODE); 

CLOSE (BASE); 
end  CREATE _NGDE; 

procedure  CREATE_NODE(BASE:  in  N0DE_TYPE; 

KEY:  in  RELATICNSHIP_KEY  :«IATEST_KEY; 

RELATION:  in  RELATICN_NAME  :» 

DEFAULT_RELATICN  ; 

ATTRIBUTES:  in  LIST_TYPE  :■  EMPTY _LIST; 

ACCESS JODNTROL:  in  PORMJ3TRING  :«  ,,H; 
LEVEL:  in  roRM_STRING  :-  ""); 

is 

NODE:  NODE_TYPE; 
begin 

CREATE_NCCE  (NODE,  KEY,  RELATION,  A3TRIBL7TES,AOCESSjXNrROL,  LEVEL)  ; 
CLOSE  (NODE) ; 
end  CREATE_NODE; 

procedure  CREATE_NODE (NAME :  in  NAME_STRING; 

ATTRIBUTES:  in  LIST  TYPE  :■  EMPTY  LIST; 

ACCESSjOGOTROL:  in  “  FORM  STRING  7- 
LEVEL:  in  FORMJ3TRING  7-  Mn); 

is 

NODE:  NODE_TYPE; 
begin 

CREATE_NCOE ( NODE ,  NAME,  ATTRIBUTES,  ACCESS JXNTRQL,  LEVEL); 
CLOSE (NODE); 


5.2  CMS  process  nodes 


This  section  describes  the  semantics  of  the  execution  of  Ada 
programs  as 

represented  by  CMS  processes  and  the  facilities  provided  by  the 
CMS  for  initiating  and  controlling  processes. 

The  major  events  in  a  process's  life  are: 

a.  Initiation 

b.  Ruining,  \rfoich  may  include  suspension  or  resumption 

c.  Termination  or  abortion 

This  section  of  the  CMS  defines  facilities  to  control  and 
coordinate  the  initiation,  suspension,  resumption,  and  termination  or 
abortion  of  processes. 

A  process  is  said  to  be  "terminated"  When  the  subprogram  Which  is 
its  main  program  (in  the  sense  of  CUVti  10.1)  has  terminated  (in  the 
sense  of  CUM]  9.4).  See  also  the  notes  in  ClRti  9*4.  Thus, 
termination  of  a  process  takes  place  whan  the  main  program  has  been 
aanpleted  and  all  tasks  dependent  an  the  min  program  have  terminated. 

A  process  may  be  "aborted"  either  by  itself  or  by  another  process. 
Aborting  a  procsss  can  be  considered  pre-emptive  termination  and  may  be 
initiated  by  the  process  itself  or  by  another  process  with  sufficient 
access  rights. 

The  following  rules  apply  to  process  nodes  for  vhich  the  process 
has  terminated  or  aborted: 

a.  The  process  node  remains  in  existence  vxitil  explicitly 
deleted. 

b.  Any  processes  in  the  process  tres  emanating  from  the 
terminated/aborted  process  have  terminated  or  aborted. 


TWo  mechanisms  for  a  process  to  initiate  another  process  are 
provided: 

a.  Invoke  -  the  procedure  l£MQKE_PROCESS  does  not  return 
aontrol  to  the  calling  task  until  this  initiated  process  has 
terminatsd  or  aborted.  Execution  of  the  calling  task  is 
blocked  until  termination  or  abortion  of  the  initiated 
process,  but  other  tasks  in  the  initiating  ptoceaa  execute 
in  parallel  with  the  initiated  process  and  its  tasks. 
Execution  of  the  initiating  task  is  syndironizsd  with  the 
initiated  procsss,  vdoich  has  no  inplicit  effect  on  other 
tasks  of  the  initiating  process.  This  kind  of  process 
initiation  is  analogous  to  calling  the  specified  program  as 
a  procedure. 
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b.  Spawn  -  the  procedure  SPANN  PROCESS  returns  after 
initiating  the  specified  program*  The  initiating  process 
and  the  initiated  process  run  in  parallel,  and,  within  each 
of  these,  their  tasks  execute  in  parallel.  The  processes 
nil  asynchronously,  except  as  they  are  synchronized  by  the 
use  of  other  AIS  facilities.  This  kind  of  process 
initiation  is  analogous  to  activation  of  the  specified 
program  as  a  task. 

Every  process  node  has  three  predefined  attributes*  RESULTS JLIgT ,  Which 
can  be  used  to  store  uaerxief ined  strings  giving  intermediate  results  of 
the  process;  PARAMEIER_LIsr,  which  contains  the  parameters  with  which 
the  process  was  called;  and  CURRENT_STATUSf  which  gives  the  current 
status  of  the  process.  In  addition,  every  process  node  has  several 
predefined  attributes  *hich  provide  information  for  standardized 
debugging  and  performance  measurement  for  processes  within  the  CAIS 
implementation.  One  of  these  predefined  attributes  has  an 
inplementation-independant  value.  This  attribute  is  HANEt£S_OPQJ,  which 
gives  the  rutfcer  of  open  node  handles  the  process  has.  The  remaining 
predefined  attributes  have  loplemantaticsirdependent  values  and  should 
not  be  used  for  caparison  with  values  from  other  CAIS  implementations . 
STARTjrTME  and  FDHSHTIMB  give  the  times  of  activation  and  termination 
or  abortion  of  the  process.  MAOIINE_TIl£  gives  the  length  of  time  the 
process  was  active  on  the  logical  processor,  if  the  process  has 
terminated  or  aborted,  or  zero,  if  the  process  has  not  terminated  or 
aborted.  IOJUNITS  gives  the  nuntoer  of  I/O  mite  used.  SIZE  gives  a 
measure  of  the  size  of  the  process. 

Far  purposes  of  input  and  output,  every  process  nods  has  several 
predefined  relationships.  These  predefined  relationships  are  ranted 
STANDARD  INPUT,  STANDARD  OUTPUT,  STANDARD_ERRDR,  CURRENT_INPUr, 
CURRENT  OUTPUT,  and  CURRENTJERROR.  STANDARD  INPUT,  STANDARD_OUTPUT  and 
STANDASU  BOOR  are  relationships  established  at  job  creation  to  the 
default  Trput,  output  and  error  files,  respectively.  The  STANDARD_INPUr 
and  STANDARD  OUTEUT  files  conform  to  the  semantics  given  far  these  in 
CUM]  14.3.27  CURKENTJNFUT,  CURHENTJJUIFUr  and  CURRQfT_ERRDR  are 
relationships  established  by  a  process  to  alternative  files  to  be  used 
as  the  default  input,  output  and  error  files,  respectively. 
CURRDVr_INPUr  and  CURRENTJXTTPUT  also  conform  to  ths  semantics  of  [LRM] 
14.3.2.  Interfaces  are  provided  in  the  CAIS  Input/Output  packages 
♦(Section  5.3)  to  read  these  predefined  relationships  and  to  change  the 
value  of  CURRENT  INPUT,  CURRENT  CUIWT,  and  CURRENT  ERROR. 
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5.2. 1  Package  GMS_PBOCESS_DQTNrnCNS 

This  package  defines  the  types  and  exceptions  associated  with 
process  nodes. 


type  PROCESS  STARS  is 

_  (READ?,  SUSPENDED'  ABORTED,  TERMINATED); 

The  PROCESS  STATUS  is  the  state  of  a  process.  Table  VII  indicates  the 
states  and  tRe  events  which  will  cause  transition  fran  one  state  to 
another. 
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When  a  process  has  terminated  or  aborted,  the  final  status, 
recorded  in  the  predefined  process  node  attribute  CURRB?T_STKIUS,  will 
persist  as  long  as  the  process  node  exists.  Any  open  node  handles 
emanating  from  a  process  are  closed  after  the  process  is  terminated  or 
aborted. 

The  PROCESS  STATUS  of  a  process  will  be  returned  to  any  task 
awaiting  the  termination  or  abortion  of  the  process  whenever  the  process 
is  terminated  or  aborted.  If  the  process  has  already  been  terminated  or 
aborted  at  the  time  a  call  to  ANAIT^PROCESSjXEVIzriGN  is  made,  then  the 
PRXESS_SEATUS  is  immediately  available.  — 

PR0CESS_STKn5  may  also  be  examined  by  the  QMS  procedures 
STATE_GF_PRXESS  and  (ZTJBSUUTS. 

HDOT_PRXESS  J  constant  NAME  STRING  " 'CURRENT  JOB"; 

aJRRDtr_NDCe  :  constant  NA»CJHRING  " ' CURROTT  NODE" ; 

OURRDiriNEVr  ;  oonstant  NAME~ STRING  *•  " '  CURRE»T_INPUTM  ; 

CURRENTJXTTPOT:  oonstant  NAME  STRING  t-  "‘CURRENT  OUTPUT"; 

CURRENTJERROR  t  constant  NAtCSTRING  *■  "'CURRENT! ERROR"; 

CURRENT JPROCESS*  STRING  renaUMB- 3AIS JE3CE JgFINITICgS  .  OJKKENTJPRXESS  ; 

ROOT_PROCESS  and  CURRENT_PROCESS  are  two  strings  defined  to  represent, 
respectively,  the  root  process  of  the  current  job  and  the  current 
process. 

Table  VIII  presents  an  overview  of  interfaces  to  change  the  status, 
review  results,  or  determine  predefined  attribute  values  in  a  process. 

TABLE  VIII.  Process  Interfaces 


These  three  procedures  change  the  process  status 
of  a  process.  Because  of  timing  circumstances  in 
a  distributed  environment,  a  change  to  the 
process  statue  my  not  take  effect  immediately. 
In  particular,  a  process  may  terminate  before 
ABORT_PROCESS  or  SUSPENDJPROCESS  is  enacted. 

procedure  ABQRT_PROCES 
procedure  SUSPEND  PRXESS 
procedure  RESUhG  PROCESS 


Determining  the  value  These  procedures  read  the  predefined  attributes 

of  a  predefined  on  process  nodes. 

attribute 

function  HANDLES  OPEN 
function  IOJUNirS' 
function  SIAFT_TIMS 
function  FINISH  TD® 


Changing  the  status 
of  a  process 
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function  MACIIINE__TD® 

Results  from  tasks 
in  a  process 

These  two  procedures  provide  the  techniques 
for  a  process  to  examine  and  modify  a 
results  list.  The  results  list  is  returned 
to  a  task  Which  named  that  process  in  a  call 
to  INVOKE  PROCESS  or  AHMT  PROCESS  COMPLETION. 

The  results  list  can  be  examined  before  or 
after  process  termination  or  abortion  by  any 
process  with  the  appropriate  access  rights. 

procedure  WRITEJRESULTS 
procedure  APPENDJRESULTS 

5.2.2  Package  (MSJPROCESSJXNITCL 


5. 2. 2.1  Types,  subtypes,  oonstants,  and  exceptions 

subtype  LIST_TYPE  is  CMS  LIST  UTILITIES .  LIST_TYPE  ; 

subtype  RESULTSJIST  is  CMSJLISTJOTUTIES .  LISTTYPE  ; 
subtype  RESUUTSJ9TRING  is  STRING;  ~ 

subtype  PARAMETER_LISr  is  CMS  LEST  UTILITIES  .IdST_TYPE; 
subtype  NAME_STRING  is  CMS_NOCE~ OEETNITICNS .  NAME_STRIN3 ; 

subtype  REUTIGNjmC  is  CMS JCDE~EEFINmCNS .  FHAnCN_NAME ; 
subtype  RELATICNSHIP_KEf  is  (MSJ<DEJXFTNITICNS .  RELATICNSHIP_KEY; 
subtype  NODEJTTPE  is  CMSJSCOEJXFINITICNS  .NCDE_TYPE ; 

subtype  PROCESSJSTKTUS  is  CMS~~ PROCESS  CEFBUTICNS .  PRXESS  STATUS ; 


MTY_LISTi  constant  LIST_TYPE  renames 

CMSJ^STJJTILITIES  .EMPIYJJST; 

IATEST_KEY:  constant  REIATICMSHIPJCET  renames 

CMS _NCCE JOEFINinCNS .  LATESTKEY ; 

DO’AULT_RHAITCNi  constant  RELATION  NAME  renames 

(MS  NODE  EEFINITCCNS. DEFAULT  REXATICN; 


NMC_ERROCU  exception 
USE_BBCRs  exception 


CAIS_NCCE_DEFINmCNS .  NAMEJERHOR; 
CMS  NODE  DEFINITIONS. USE  ERROR; 


HHTOT_VI<XAnCN*  exception  renames 

CMSJDOEJDEFINnTCNS .  INTENTJ/IOAnCN ; 
ACCESS  VIOCATIONi  exertion  renames 

(MS  NODE  DEFINITIONS . ACCESS  VIOLATION; 
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SBC3JRITY_VICLATICN :  exception  renames 

CAIS JPDE_CEF1NIT10NS .  SBCURITY_VICLftTION  ; 

NAJ«_ERROR  is  raised  whenever  an  attaipt  is  made  to  access  a 

node  via  a  pathname  or  node  handle  wfriile  the  node 
does  not  exist,  is  unobtainable,  discretionary 
access  controls  for  knowledge  of  existence  of  a  node 
are  violated,  or  mandatory  access  oontrols  for  read 
operations  are  violated. 

USE_ERROR  is  raised  whenever  a  restriction  on  the  use  of  an 

interface  is  violated. 

mTEOT_VICLOTCN  is  raised  whenever  an  operation  is  attenpted  on  an 
open  node  handle  which  is  in  violation  of  the  access 
intent  specified  when  the  node  handle  was  opened. 

MX3SS_VI(XA3T0N  is  raised  whenever  an  operation  is  attenpted  vrtiich 
violates  access  right  constraints  other  than 
knowledge  of  existence  of  the  node. 

SE)CURITY_yiQLATIGN  is  raised  whenever  an  operation  is  attonpted  which 
violates  mandatory  access  oontrols. 


5. 2. 2. 2  Spawning  a  process 

procedure  SPAWN_PROCESS 
(NODE: 

FH£  NOOE: 

INPOT_PARAMETERS: 

KEY: 

RELATION : 

ACCESS_CCNTHQL: 

LEVEL: 

FORM: 

MPOT_ETLE: 

CUTPUT_FILE: 

E3*HDR_FH£: 

ENVIROtWENTJCDE: 

Purpose: 

This  procedure  creates  a  new  process  node  vhoee  contents  represent 
the  execution  of  the  program  contained  in  the  specified  file  node. 
SPMfNJPROCESS  accepts  a  list  of  parameters  and  makes  it  available  to 
the  new  process  via  the  procedure  GET_PARAME7TERS.  Control  returns 
to  the  calling  task  after  the  new  node  is  created.  The  process  node 
containing  the  calling  task  must  have  execution  rights  for  the  file 
node.  The  created  process  node  has  secondary  relationships  to  the 
input,  output,  and  error  files.  An  open  node  handle  on  the  new  node 
is  returned,  with  an  intent  establishing  all  access  ri^its. 
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in  out  NOOEJTYFE; 
in  NDCEJTYPE; 

in  PARAMETER_LIST; 

in  RELATICNSHIP_KEY  :*  LATEST_KEY; 

in  FHATICN_NAME  :■  DEFAJJLT_RELATION ; 

in  EOFMJ5TRING  :- 

in  roFMJSnUNS  :- 

in  LISTJTYPE  :■  EMPTY_LIsr; 

in  NftMEjSTRING  :■  CURRENT_INPirr; 

in  NAMEJSTRING  :■  CXJRREOTjXTFPirr; 

in  NRME_STRING  :■  CURHENTJEFRDR; 

in  NAIVE  STRING  CURRENT  NODE); 
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The  AOCESSjXNrRCL  parameter  specifies  the  initial  access  control 
information  to  be  established  for  the  created  node.  The  current 
user  must  have  all  access  rights  to  the  created  node. 

The  LEVEL  parameter  specifies  the  security  level  at  which  the  node 
is  to  be  created. 

Parameters: 

NODE  is  a  node  handle  returned  on  the  newly  created 

process  node. 

FTUE_N3DE  is  a  node  handle  on  the  file  node  containing 

the  executable  image  vhose  execution  vail  be 
represented  by  the  new  process. 

INEVTJPARAMETERS  is  a  list  containing  process  parameter  information. 

The  list  is  constructed  and  parsed  using  the 
tools  provided  in  CMS_LIST JJTILITIES ( Section  5.4). 
INPOT_PARAMETERS  is  stored  in  a  predefined 
attribute  PARAMETERLIST  of  the  new  node. 

is  the  relationship  key  of  the  primary 
relationship  from  the  current  process  node  to  the 
new  process  node.  The  default  is  supplied  by  the 
mechanism  of  interpreting  the  LATEST_KEY  constant. 

is  the  name  of  the  primary  relation  fron  the 
current  process  to  the  new  node.  The  default  is 
DEFAULT  JRELATICN . 

PCCESS  CENTRQL  is  a  string  defining  the  initial  access  oontrol 
information  associated  with  the  created  node.  The 
current  user  must  have  all  access  rights  to  the 
created  node. 

LEVEL  is  a  string  defining  the  classification  label  for 

the  created  node. 

EORM  is  a  list  vfoich  can  be  used  to  set  attributes 

in  the  new  node.  It  could  be  used  by  an 

implementation  to  establish  allocation  of 

resources. 

INPOTP3IZ, 

CUIFOTJTIE,  and 

ERRDR_FTL£  are  path  names  to  file  nodes  for  the  new  process 


ENVI!VNMENr_NCD&  is  the  node  the  new  process  will  have  as  its 
initial  current  node.  The  default  value  is 
CURRENT  NODE  of  the  initiating  process. 


KEY 


RELATION 


Exceptions: 
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NAME_ERRDR  is  raised  if  the  node  indicated  by  FILE_NODE  is 

inaccessible  or  unobtainable  or  if  a  node  ""already 
exists  for  the  relationship  specified  by  KEY  and 
RELATION. 

USE_ERROR  is  raised  if  it  can  determined  that  the  node 

indicated  by  FH£_NOCE  does  not  contain  an 
executable  image. 

LOCKJERROR  is  raised  if  the  node  designated  by  FILE_NOQE  is 

locked  against  execution. 

INrENT_VI(XATION  is  raised  if  the  node  designated  by  FIL£_NODE  was 
not  opened  with  an  intent  establishing  the  ricflrt 
to  execute  contorts. 

Notes: 

SPAWN_PROCESS  does  not  return  results  or  process  status.  If 
ooordinaticn  between  any  task  and  the  new  process  is  desired, 

AWAIT  PROCESS_OOMP1£TTCN  or  the  techniques  provided  in  CAIS 
Input/Output  *( Section  5.3)  must  be  used.  When  the  parent  process 
terminates  or  aborts,  the  child  process  will  be  aborted. 


5. 2. 2. 3  Awaiting  termination  or  abortion  of  another  process 

procedure  AWMT_PROCESS_COMETiJHCN 

(NODE:  in  NOCEJIYPE; 

RESULTS JREJTURNEE:  in  out  RESULTS  LIST; 

STATUS:  Out  PROCESS JSEATUS; 

TIMELIMIT:  in  DURATION  :»  DURATION' IAST ) ; 

Purpose: 

This  procedure  suspends  the  calling  task  and  waits  for  the  process 
identified  by  NODE  to  terminate  or  abort.  The  calling  task  is 
suspended  until  the  identified  process  terminates  or  aborts  or  until 
the  time  limit  is  exceeded. 

AWAIT JPRDCESSJXMPLETION  returns  the  results  list  and  process 
oonpletion  status  to  the  calling  task,  even  if  the  process  has 
already  terminated  or  aborted  when  the  call  is  made,  so  long  as  the 
process  node  exists. 

Parameters: 

NODE  is  an  open  node  handle  for  the  process  to  be  awaited. 

RESULTS_REIURNED  is  a  list  of  results,  which  are  represented  by 
strings,  from  the  process.  The  individual  results  may 
be  extracted  from  the  list  using  the  tools  provided 
in  CMS  LIST  UTILITIES. 


PROPOSED  MIL-SID-CAIS 
31  OCT  1984 


STATUS  gives  the  process  status  of  the  process.  If 

termination  or  abortion  of  the  identified  process  can 
be  reported  within  the  specified  time  limit,  STATUS 
will  have  the  value  ABORTED  or  TERMINATED.  If  the 
process  does  not  terminate  or  abort  within  the  time 
limit,  STATUS  will  have  the  value  READY  or  SUSPENDED. 

TIME_LIMrr  is  the  limit  cn  the  time  that  the  calling  task  will 
be  suspended  awaiting  the  process.  When  the  limit  is 
exceeded  the  calling  task  resumes  execution.  The 
default  is  the  implementation-dependent  maximum  value 
for  DURATION. 


Exceptions: 
NAME  ERROR 


LOCK  ERROR 


is  raised  if  the  identified  node  is  inaccessible  or 
unobtainable. 

is  raised  if  the  identified  node  is  locked  against 
reading  attributes. 


IOTEOT_VICtAriCN  is  raised  if  the  designated  process  node  was  not 
opened  with  an  intent  establishing  the  right  to 
read  attributes. 


SBCURITY_VIOLATION  is  raised  if  the  attempt  to  access  the 
identified  node  represents  a  violation  of  mandatory 
access  controls.  SEXTJRTTY^VIQLAITCN  is  raised  only 
if  the  conditions  for  theTbther  exceptions  are  not 
satisfied. 


5. 2. 2.4  Invoking  a  new  process 


procedure  INVCKE_PROCESS 

(ETLEJ3CDE:  in 

INPl7r_PARAME3ERS:  in 
RESUUTS__RErrURNED:  in 
STATUS: 

KEY:  in 

RELATION:  in 

ACCESS JOCNTRQL:  in 

LEVEL:  in 

FORM:  in 

INFUr_FTLE:  in 

CUTPOTETLE:  in 

EKROR_ETLE:  in 

ENVIROWENTJJODE:  in 
TIME  LIMIT:  in 


NODE_TYPE? 

P ARAMETER_LJ  ST ; 
out  RESULTS  LIST ; 

Out  PROCESSJSTAIUS; 

REIAnCNSHIP_KEY  :■  LATEST_KEY; 
RE1ATICN_NAME :  *  DEFAULT_RELATICN ; 
EORM_STRING  :=* 

EURM_STRING  :■  MM; 

LISTJTYPE  :*  EMPTYJLISTy 
NAME_STRING  :»  CURRH?T_INFUT; 
NAME_STRING  :  “CURREOTjDUTPUT  ; 
NAMEJSTRING  :■  CURREJ7T_ERRORr 
NAME_STRING  :*  CURRENTJCDE; 
DURATICN  :■  DURATION* LAST; ) 


Purpose: 

This  procedure  provides  the  functionality  of  a  call  to  SPAWN_PROCESS 
followed  by  a  call  to  AWAIT  PROCESS  COMPLETION,  as  an  indivisible 
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operation. 

INVOKE  PROCESS  creates  a  new  process  node  Whose  contents  represent  the 
execution  of  the  program  contained  in  the  specified  file  node. 
INVCKEJPROCESS  accepts  a  list  of  parameters  and  makes  it  available  to 
the  new  process  via  the  procedure  GET_PARAMETERS.  If  termination  or 
abortion  of  the  identified  process  can  be  reported  within  the 
specified  time  limit,  control  is  returned  with  the  process  status. 
Otherwise  control  is  returned  When  the  specified  time  limit  is 
exceeded  with  a  status  of  READ?  or  SUSPENDED.  The  process  node 
containing  the  calling  task  must  have  execution  rights  for  the  file 
node.  The  created  process  node  has  secondary  relationships  to  the 
input,  output,  and  error  files. 

The  AOCESSJXNTRQL  parameter  specifies  the  initial  access  control 
information  to  be  established  for  the  created  node,  as  described  in 
♦(Section  5.1.4).  The  current  user  must  have  all  access  rights  to  the 
created  node.  The  LEVEL  parameter  specifies  the  security  level 
at  which  the  node  is  to  be  created,  as  described  in  *( Section  5.1.4). 

Parameters: 

FILE_NODE  is  an  open  node  handle  on  the  file  node  containing 

the  executable  image  whose  execution  will  be 
represented  by  the  new  process. 

INP17T_PARAMETERS  is  a  list  containing  process  parameter  information. 

The  list  is  constructed  and  parsed  using  the  list 
handling  tools  of  CaiS_LISTJJriLITIES.  INPUT- 
PARAMETER  is  stored  in  the  predefined  attribute 
PARAMETER_LIST  of  the  new  node. 

RESULTS_RETURNED  is  a  list  of  results  thich  are  represnted  by 
strings  frcxn  the  new  process.  The  individual 
results  may  be  extracted  from  the  list  using  the 
tools  Of  CAIS JalSTJJCTLITIES . 

gives  the  process  status  of  the  process.  If 
termination  or  abortion  of  the  identified  process 
can  be  reported  within  the  specified  time  limit, 
STATUS  will  have  the  value  ABORTED  or  TERMINATED. 

If  the  process  does  not  terminate  or  abort  within 
the  time  limit,  STATUS  will  have  the  value 
READY  or  SUSPENDED. 

is  the  relationship  key  of  the  primary  relationship 
from  the  current  process  node  to  the  new  process 
node.  The  default  is  supplied  by  the  LATEST_KEY 
function. 

RELATION  is  the  name  of  the  primary  relation  fran  the 

current  process  node  to  the  new  node.  The  default 
is  DEFAULT  RELATION. 


STATUS 


KEY 
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ACCESSjXNTRCL  is  a  string  defining  the  initial  access  control 
information  associated  with  the  created  node.  The 
current  user  must  have  all  access  rights  to  the 
created  node. 

LEVEL  is  a  string  defining  the  classification  label  for 

the  created  node. 

FORM  is  a  list  which  can  be  used  to  set  attributes  of 

of  the  new  node.  It  could  be  used  by  an 
inplementation  to  establish  allocation  of  resources. 

INPOT_FILE, 

OOTPITTJBTLE,  and 

ERROR JFTLE  sure  path  names  to  file  nodes  for  the  new  process 

node. 

ENVIRCNMENr_NODE  is  the  node  the  new  process  will  have  as  its 
current  node.  The  default  is  CURRENTJSIOCE  of  the 
invoking  process. 

TIME_LIMIT  is  the  limit  on  the  time  that  the  calling  task  will 
be  suspended  awaiting  the  new  process.  When  the 
limit  is  exceeded,  the  calling  task  resumes 
execution.  The  default  is  the  inplementation- 
dependent  maxinun  value  for  DURATION. 

Exceptions: 

NAME_ERROR  is  raised  if  the  node  indicated  by  FlLE  jSJCOE  is 

inaccessible  or  unobtainable  or  if  a  node  already 
exists  for  the  relationship  specified  by  KEY  and 
RELATION. 

USE_EEROR  is  raised  if  it  can  be  determined  that  the  node 

indicated  by  FTLE_NOCE  does  not  contain  an 
executable  image. 

LOCKJERROR  is  raised  if  the  node  designated  by  ETI£_NODE  is 

locked  against  execution. 

INTENTJ/IOIATION  is  raised  if  the  node  designated  by  FTLE_NODE  was 
not  opened  with  an  intent  establishing  the  right 
to  execute  contents. 
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5. 2. 2. 5  Crating  a  nw  job 

procedure  CRSVni  JOB 

(FILE  NCCE:  in 

ESSHT  PARAMETERS  t  in 
KEY*  “  in 

aocesS-Ocnircl*  in 

LEVEL* —  in 

FORM*  in 

DSVr_FZLE*  in 

CUTPl7r_FIIE*  in 

ERROR  FILE:  in 

EMVTICEBCtirjXXEi  in 

Purpose* 

This  procedure  creates  a  new  root  process  node  whose  contents 
represent  the  execution  of  the  program  contained  in  the  specified 
file  nods.  CREA3E_JCB  establishes  the  USER,  ROUE,  and  DEVICE 
relationships  as  described  in  ‘(Section  4),  General  Requirements. 
CREATE— JOB  accepts  a  list  of  parameters  and  mricae  it  available  to 
the  new  process  via  the  procedure  GET  PARAMETBtS.  Control  returns 
to  the  calling  task  after  the  new  jc£>  is  created.  The  process  node 
containing  the  calling  task  mist  have  execution  rirpits  for  the  file 
node  and  appandjralatianahip  rights  to  CURRBUT  USER.  The  new  job 
has  secondary  relationships  to  the  input,  output, “and  error  files. 
A  new  primary  JOB  relationship  is  established  from  CURRENT  USER  to 
the  new  job. 

The  ACCESSjXNTROL  parameter  specifies  the  initial  access  control 
information  to  be  established  for  the  created  node.  The  current 
user  must  have  all  access  rights  to  the  created  nods. 

The  LEVS,  parameter  specifies  the  security  level  at  which  the  node 
is  to  be  created. 

Parameters* 

ETL£_NXe  is  an  qpsn  nods  handle  on  the  file  node  containing 

the  executable  image  whose  execution  will  be  by 
the  new  process. 

INPUT-PARAMETERS  is  a  list  containing  process  paxmnstar  lnfr»rn«*H<fv 
The  list  is  constructed  and  parsed  using  the  tools 
provided  in  CAIS-LIST-UnLITIES. 

KEf  is  the  relationship  key  of  the  primary  JOB 

relationship  from  the  current  user  node  to  the  new 
Process  node.  The  default  is  sippliad  by  the 
LATEST  KEY  function. 


ACCESS— OCNTRCL  is  a  string  defining  the  initial  access  control 

information  associated  with  the  created  nods.  The 
current  user  must  have  all  access  rights  to  the 


NCOS  TYPE; 

PARMCTER  LIST; 

SEIXITCNSHIP  KEY  *-  IATEST  KEY; 
FORM  STRING  7-  ~ 

FCRTsTRING  *■  “; 

LIST-TYPE  *-  EMPTY— LIST; 

NAME  STRING  *■  CURRENT  INRJT; 
NAFC- STRING  *-  CURRENT  < CUIWT; 
NAME  JTKTNG  *«  CURRENT- ERROR; 
NAFS- STRING  *-  CURRENT- USER); 
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created  node. 

LEVEL  ia  a  string  defining  the  classification  label  for 

the  created  node. 

EOHM  is  a  list  tahidi  can  be  used  to  set  attributes 

of  the  new  node.  It  could  be  used  by  an 
implementation  to  establish  allocation  of 
resources. 

INPUT _FHE, 

armJTJTIE,  and 

H?ROR_FILE  are  path  names  to  file  nodes  for  the  new  process 

node. 

ENVIRCMOn^NCOE  is  the  node  the  new  process  will  have  as  its 
~  initial  current  node.  The  default  value  is 
CURBEOTJJSER  of  the  current  process. 

Exceptions! 

NM£JBOOR  is  raised  if  the  node  indicated  by  FHE_NQOE  is 

inaccessible  or  unobtainable  or  if  a  node  already 
exists  for  the  relationship  specified  by  KEY  and 
RQATICN. 


USE_ERROR  is  raised  if  it  can  determined  that  the  node 

indicated  by  ETJ£_NCOE  does  not  contain  an 
executable  image. 

LOCKJERROR  is  raised  if  the  node  designated  by  ETXE_ICDE  is 

locked  against  execution. 

mnsnMTEGUSEN  is  raised  if  the  node  designated  by  ETI£_NOOE  was 
not  opened  with  an  intent  establishing  the  right 
to  execute  contents. 

AOCESS_VIQLAncN  is  raised  if  the  current  proosss  does  not  have 
sufficient  discretionary  access  rights  to  open  the 
current  user  node  with  APPEND  RELATIONSHIPS  intent. 
AGCESS_yiGCATICN  is  raised  ariTy  if  the  conditions 
for  NNfejERRCR  are  not  satisfied. 

SEX3JRTIY_VI(XAITCN  is  raised  if  the  attenpt  to  obtain  access  to 
CURRDTTJJSER  or  the  file  nods  represents  a 
violation  of  mandatory  access  aontrols  for  the 
CMS.  SEXDRm_VIOLATICN  is  raised  only  if  the 
conditions  for  raising  the  other  exertions  are  not 
satisfied. 

Notesi 

CREATE_JCB  does  not  return  results  or  process  status  to  the  calling 
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program  unit.  If  coordination  between  any  program  unit  and  the  new 
process  is  desired,  AWAIT  PROCESS  OQMPLETICN  or  the  techniques 
provided  in  CAIS  Input/Output  *( Section  5.3)  must  be  used. 

The  relation  name  for  the  primary  relationship  to  the  new  node  is 
JOB. 


5. 2. 2.6  Appending  results 

procedure  APPEUD  RESUI ■T'S  ( BESOMS »  in  HESULTS^STTRINS); 


Purposex 

This  procedure  adds  its  specified  results  parameter  to  the  list  of 
results  Cron  other  calls  to  APPQD  RESULTS  in  the  current  process. 
The  procedure  appends  results  to  tfie  list  in  the  order  in  vhich  they 
are  received.  Upcn  termination  or  abortion  of  the  current  process, 
the  results  list  is  returned  to  any  task  which  named  this  process  in 
a  call  to  AWAIT_PRDCESSj3M?Ljm:CN  or  nM*E_PROCESS. 

Parameters! 

RESULTS  is  a  string  to  be  stared  in  the  RESULffiS_LIST 

attribute  of  the  current  proceee  node  and 
ultimately  returned  to  the  awaiting  or  invoking 
task. 

Exceptions! 

None. 

Notes: 

Until  the  proceee  node  is  deleted  or  the  results  are  overwritten, 
the  results  are  stared  in  a  results  list  which  is  th  evalue  of  the 
CMS  predefined  attribute  RESULTS_LIsr. 


5. 2. 2. 7  Overwriting  results 

ptooedure  WRTIE_RESULTS  (RESULTS  :  in  RESULTSJ9TRING); 

Purpose: 

This  procedure  replaces  the  current  list  of  results  with  the 
specified  results. 

Parameters: 

RESULTS  is  a  string  to  be  stored  in  the  RESULTS_IJSr  and 

ultimately  returned  to  the  awaiting  or  invoking 
task. 

Exceptions: 

None. 
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5. 2. 2. 8  Getting  results  from  a  process 

procedure  GET  RESULTS  (NODE:  in  NCDETYPE; 

“  RESULTS!  in  out  RESULTS  LIST; 

STATUS!  out  PROCESSJSTMUS); 

Purpose!  _  _ 

This  procedure  reads  the  attributes  RESULTS_LIST  and  CURRQ?T_SIAIUS 
associated  with  a  process  node.  The  process  need  not  have 
terminated  or  aborted.  The  empty  list  is  returned  in  RESULTS  if 
WRITE  RESULTS  or  APPESD_RESULTS  has  not  been  called  in  the  process 
contained  in  NODE. 

Parameters: 

NUDE  is  an  open  node  handle  cn  a  process  node. 

RESULTS  is  a  list  resulting  fran  calls  made  by  program 

wits  in  the  process  node  to  the  procedures 
WRTTE_RESULTS  and  APPH®_RESULTS.  The  individual 
results  may  be  extracted  from  the  list  using  the 
tools  of  CAIS _LIsr_<jniiXTIES  ‘(Section  5.4) . 

STATUS  is  the  prooess  status  of  the  process. 

Exceptions: 

NAME  ERROR  is  raised  if  the  node  identified  by  NUDE  is 
inaccessible  or  unobtainable  or  is  not  a  process 
nods. 

LOCK JERRQR  is  raised  if  the  node  identified  by  NUDE  is  locked 

~  against  reading  attributes. 

IMTNTJ/ICLAITCN  is  raised  if  the  identified  process  node  was  not 
opened  with  an  intsnt  establishing  the  right  to 
read  attributes. 

SECURITY_yi<XA3TCN  is  raised  if  the  attanpt  to  obtain  access  to  the 
node  identified  by  NODE  represents  a  violation  of 
mandatory  access  controls  for  the  OHS.  SBCURITY_ 
VIOLATION  is  raised  only  if  the  conditions  for 
raising  the  other  exceptions  are  not  satisfied. 

Additional  Interfaces: 

procedure  (ZT  RESULTS  (NODE:  in  NODE  TYPE; 

RESULTS:  in  out  RESULTS  LIST) 

is  ” 

STATUS:  PRCCESS_STATUS; 

begin 

GET  RESULTS  (NODE,  RESULTS,  STATUS); 

end  <afT_RESULTS; 


procedure  CZTT  RESULTS  (NMC: 


in 


NAPE  STRING; 


i  u  m 
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5.2.2.10  Aborting  a  process 

procedure  ABOKTJPRDCESS  (NODE :  in  NCDEJIYPE; 

*”  RESULTS:  in  RESULTSJSTRING ) ; 

Purpoeet 

this  procedure  aborts  the  process  cantained  in  NODE  and  fare ee  any 
processes  in  the  subtree  rooted  at  the  identified  process  to  be 
aborted.  The  order  of  the  process  abortions  is  not  specified.  If 
the  state  of  the  aborted  process  is  examined,  it  will  be  ABORTed 
provided  that  the  process  existed  and  was  not  terminated  at  the  time 
of  the  call  to  ABORT_PROGESS.  The  node  associated  with  the  aborted 
process  ranine  ixrtil  explicitly  deleted. 

Parameters! 

NODE  is  an  open  node  handle  for  the  node  of  the  process 

to  be  aborted. 

RESULTS  is  a  string  to  be  appended  to  the  RESUUTS_LIST 

attribute  of  the  node  of  the  aborted  process.  ~ 


Exceptions! 

NAJC IJ8RRDR  is  raised  if  the  process  node  is  inaccessible  or 

unobtainable. 

H/TEOT_VKXArTCN  is  raised  if  the  identified  process  node  was  not 
opened  with  an  intent  establishing  exclusive  write 
access  rights. 

SECURITY_VI(XATIGN  is  raised  if  the  attsnpt  to  obtain  access  to 
the  node  identified  by  NODE  represents  a 
violation  of  mndatcry  access  controls  in  the  CMS. 
SECURITY  VIOLATION  is  raised  only  if  the  conditions 
for  raising  the  othr  exceptions  are  net  satisfied. 


iiterthoeei 

ABORT_PHOCESS (NAME:  in  NAME  STRING; 

RESULTS!  in  RESJEl5_SIRING) 

accejrxPE; 

»(NCDE,  NAME,  (EXCLUSIVE  WRITE))? 

PROCESS (NODE,  RESULTS);  ~ 

«XE); 


when  others  »> 
CLOSE  (NODE); 
raise; 

end  ABORT  PROCESS; 


procedure  ABORT  PROCESS  (NODE i  in  NODE  TYPE) 
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begin 

ABORT  PROCESS(NCCe, 
end  ABCSffJPRDCESS; 

procedure  ABORT_PROCESS(NnMEi  in  EMCJRRING) 
is  * 

NODE:  HXejRPBt 
begin  ”*" 

era Knock,  mm,  (exclusive  write)); 

ABORT  PROCESS(l*XE,  "");  ~ 

OjOSETNOOE); 

exception 

whan  others  *> 

Oj06E(NCCE); 

raise; 

end  ABORT  PROCESS; 


Nbtees 

ABORT  PROCESS  can  be  used  by  a  task  to  abort  the  process  that 
contains  it.  Any  open  node  handles  emanating  from  NOCE  are  closed 
after  the  process  is  aborted. 


5.2.2.11  Suspending  a  process 

procedure  9USPEND_PR0CESS (NODE ;  in  NOCEJXPE); 

Purpose; 

this  procedure  suspends  the  process  contained  in  NOEE.  After 
SUSPOD  PROCESS  is  called,  the  PROCESS  STKXU5  of  the  identified 
process-  is  SUSPBOED,  provided  that  ttm  process  was  in  the  READY 
state  at  the  tine  that  the  swpanelon  took  effect.  SUSPH*>_PRDCESS 
has  no  effect  if  the  procese  is  not  in  the  f&MX  state.  — 

Parameters; 

NODE  is  an  open  nods  handle  for  the  node  of  the  process 

to  be  suspended. 

Exceptions; 

NMCJERROR  is  raised  if  the  node  is  inaccessible  or 
unobtainable  or  is  not  a  process  nods. 

INTENT JflCTATICN  is  raised  if  the  identified  process  node  was  not 
opened  with  an  intent  establishing  write  access 
rights. 

SEJCURTTYJ/ICCAnCN  is  raised  if  the  attsnpt  to  obtain  access  to 
the  node  identified  by  NOCE  represents  a  violation 
of  the  mandatory  access  controls  for  the  CMS. 
SECURITY  VIOLATION  is  raised  only  if  conditions 
for  raising  the  other  exceptions  are  not  satisfied. 

Additional  Interfaces; 
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procedure  SUSPENDJPRDCESS ( NAME s  in  NAIBJSTRING) 
is  ” 

HXEi  NCCETXPE; 
begin  ” 

OPEN(NOOE,  NAME/  (WRITE)); 

SUSPEND  PROCESS  (NOCE); 

CLOSE ( NODE ) ; 
exception 

when  others  *> 

CLOSE (NODE); 

reiser 

end  SUSPEND  PROCESS; 


Notes! 

SUSPEND_PROCESS  can  be  used  by  a  task  to  suspend  the  process  that 
contains  it. 


5.2. 2. 12  Resulting  a  process 

procedure  RESt*C_PROCESS  (NOCEi  in  NCCE_TYPE); 

Purpoeet 

This  procedure  causes  the  process  contained  in  NODE  to  resum 
execution.  RESUME_PHDCESS  has  no  effect  if  the  process  is  not 
suspended.  After  RESU£_PROCESS  is  called,  the  PROCESSJSTATUS  of 
the  identified  process  is  READ?  provided  that  the  process  was  in  the 
SUSPENDED  state  at  the  time  that  the  reeutption  took  affect. 

Parameters! 

NODE  is  an  open  node  handle  for  the  node  of  the  process 

to  be  resuaed. 

Exceptions! 

NNC_aaoR  is  raised  if  the  node  is  inaccessible  or 

unobtainable. 

nTrSfrj/IGCATXCM  is  raised  if  the  identified  process  nods  was  not 
opened  with  an  intent  establishing  write  access 
rights. 

SBCURmM/ICXATZCN  is  raised  if  the  attempt  to  obtain  access  to  the 
node  identified  by  NODE  represents  a  violation  of 
the  Mandatory  access  controls  for  the  QVIS. 
SBCUK1TYVX0LAXICN  is  raised  only  if  the 

conditions  for  raising  ths  other  exceptions  are 
not  satisfied. 

Additional  Interfaces! 

procedure  RESUW  PROCESS  (NAME:  in  NAME  STRING) 

is  "* 

NOCEi  NOCEJRPE; 

begin 
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OPBKNODE,  NAME,  (WRITE)); 
RESUMS  PROCESS  (NOCE); 
CLOSE  (NODE); 
exception 

vhs n  others  «> 

CLOSE  (NCCE); 

raise;  _ 

end  RESUME  PROCESS; 


5.2.2.13  Determining  the  state  of  a  process 

function  STMEO?  PROCESS (NODE:  in  NCCEJTYPE) 
return  HiXESSJSTAIUS; 

Purpose; 

This  function  returns  the  current  state  of  the  process  contained 
in  NOCE. 

Parameters; 

NODE  is  an  open  node  handle  for  the  process  shoes  status 

is  to  be  queried. 

Exceptions; 

NAMEJQWOR  is  raised  if  the  node  is  inaccessible  or 

^obtainable. 

IOCK_ERROR  is  raised  if  the  node  is  locked  against  reading 

attributes. 

INTQ/r_yiOLAnCN  is  raised  if  the  identified  process  node  was  not 
opened  with  an  intsnt  establishing  the  right  to 
read  attributes. 

SECURITY  VIOLATION  is  raised  if  the  attmipt  to  obtain  access  to  the 
node  identified  by  NOCE  represents  a  violation 
of  the  mndatory  access  oontrols  for  the  QMS. 
SECURITY  VIOLATION  is  raised  only  if  the  conditions 
for  raising  the  other  exceptions  are  not  satisfied. 

Additional  Interfaces; 

function  STATE_CF  PRDOSSS  (NAME :  in  NAMEJSERING) 
return  PROCESS  STATUS 

is 

NOCE;  NODE  TYPE; 

RESULT;  PFECTSS  STATUS; 

begin 

GPEN(NCCE,  NAME,  (WRITE)); 

RESULT  ;»  STATE_QF_PROCESS(NOOE) ; 

CLOSE (NOCE); 

return  RESULT; 

exception 
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when  others  -> 

GLOGE(NQCE); 

raise; 

end  STATE_CF_PROCESS ; 

Notes* 

The  process  state  of  the  process  containing  the  calling  task  will 
always  be  BEADY. 


5.2.2.14  Determining  the  timber  of  open  node  handles 

function  HANELES_OPHS  (NODE  t  in  NOOEJRPE) 

return  NATURAL; 


Purpoeet 

This  function  returns  the  value  of  the  predefined  attribute 
HANDLES  OPEN. 


NODE 


Exceptions* 

NAtCBOGR 

DOCK  ERROR 


is  an  open  node  handle  to  the  process  node  at 
interest. 


is  raised  if  the  node  is  inaccessible  or 
unobtainable. 

is  raised  if  the  node  is  locked  against  reading 
attributes. 


mmrr_VIGLAT£CN  is  raised  if  the  identified  process  node  was  not 
opened  with  an  intent  establishing  the  right  to 
read  attributes. 

SBCURXTYVIOLATION  is  raised  if  the  atbanpt  to  obtain  access  to  the 
node  identified  by  NODE  represents  a  .violation 
of  the  nandatory  access  controls  for  the  CA1S. 
SECURITY  VIOLATION  is  raised  only  if  the  conditions 
for  raising  the  other  exceptions  are  not  satisfied. 

Additional  Interfaces* 

function  HANELES_CPEN  (NA*E  *  in  NOOEJKPE) 
return  NATURAL 

is 

NODE*  NODE  TYPE; 

RESULT*  NAlfcRAL; 

begin 

CPEN(NXE,  NAME,  (WRITE)); 

RESULT  l-  HAtCLES  OPEN(NDCE); 

CT£6E(NCDE) ; 

return  RESULT; 
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exception 

whan  others  ■> 
CLOSE  (NODE); 

raise; 

end  HANDLES  OPEN; 


5.2.2.15  Determining  the  rnmfcer  of  Z/O  mite  used 

function  IOJJNTTS  (NCCE  :  in  NCCEJIYPE) 

return  NATURAL; 

Purpose: 

This  function  returns  the  value  of  the  predefined  attribute 

iojwrrs. 

Parameters: 

NCCE  is  an  open  node  handle  to  the  process  node  of 

interest. 

Exceptions: 

NAMEJSBOR  is  raised  if  the  node  is  inaccessible  or 
unobtainable. 

LOCK_ESROR  is  raised  if  the  node  is  locked  against  reading 

attributes. 

IOTENr_VICLATICN  is  raised  if  the  identified  process  node  was  not 
opened  with  an  intent  establishing  the  right  to 
read  attributes.' 

SBCURnYJ/IGLATICN  is  raised  if  the  atteept  to  obtain  to  the 

node  identified  by  NCCE  represents  a  violation 
of  the  imndatary  access  controls  for  the  CAIS. 
SECURITY  VIOLATION  is  raised  only  if  the  conditions 
far  raising  the  other  exceptions  are  not  satisfied. 

Additional  Interfaces: 

function  IOJJNTTS  (NAME  :  in  NAMEJSTRING) 
return  NATURAL 

is 

NCCE:  NCCE  TYPE; 

RESULT:  NATURAL; 

begin 

OPEN  (NCCE,  NAME,  (WRITE)); 

RESULT  10  UNITS(NOCE); 

CLOSE(NCCE)  ;~ 
return  RESULT; 

exception 

when  others  ■> 

CLOSE  (NCOS); 
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raise; 

end  10  UNITS; 


5.2.2.16  Determining  the  time  of  activation 

function  STARTJITME  (NODE  s  in  NCDETXPE) 

return  CALENDAR. TIME; 

Purposes 

This  function  returns  the  value  of  the  predefined  attribute 

SEART_TIME. 

Parameters: 

NODE  is  an  open  node  handle  to  the  process  node  of 

interest. 

Exceptions i 

NAEB  ERROR  is  raised  if  the  node  is  inaccessible  or 

unobtainable. 

LOCK_ERROR  is  raised  if  the  node  is  locked  against  reading 
attributes. 

mronM/ICLATICN  is  raised  if  the  identified  process  node  was  not 
opened  with  an  intent  establishing  the  right  to 
read  attributes. 

SECURITYJ/ICLAXICN  is  raised  if  the  attenpt  to  obtain  access  to  the 
node  identified  by  NODE  represents  a  violation  of 
the  mandatory  access  controls  far  the  CMS. 
SECURITY  VIOATICN  is  raised  only  if  the  conditions 
for  raising  the  other  exceptions  Jure  not  satisfied. 

Additional  Interfaces: 

function  SEARTjraC  (NAME  :  in  NAME_STRING) 
return  CALENDAR. TIME 

is 

NODE:  NXEJIYPEj 
RESULTS  CALENDAR. TB*:; 

begin 

GPEN(NCOEf  NAME,  (WRITE)); 

RESULT  :«  START  TIME  (NODE); 
dOSE(NCCE) ;  ~ 

return  RESULT; 

exception 

when  others  ■>• 

CLOSE  (NODE); 


r*i 

[-3 


PROPOSED  MIL-STO-CAIS 
31  OCT  1984 


I 


B 

b 

K-: 

f*.' 

L: 

f?- 
»  'w 

r\ 

*  •. 

t : 


5.2.2.17  Determining  the  tine  of  termination  or  abortion 

fmcticn  FINISH_TDB  (NODE  :  in  NCOEJTYFE) 

—  return  CAIE(E)AR.TOC? 

Purpose: 

This  function  returns  the  value  of  the  predefined  attribute 
FINISH  TO®. 


Parameters: 

NODE 


Exceptions: 
NAME  ERROR 


LOCK  ERROR 


is  an  open  node  handle  to  the  process  node  of 
interest. 


is  raised  if 
unobtainable. 


the  node  is  inaccessible  or 


is  raised  if  the  node  is  located  against  reading 
attributes. 


OREOTJ/ICLASTON  is  raised  if  the  identified  process  node  was  not 
opened  with  an  intent  establishing  the  right  to 
read  attributes. 


£ 


SEX3IRITY_VICtAnON  is  raised  if  the  attempt  to  obtain  access  to  the 
node  identified  by  NOCE  represents  a  violation 
of  the  mandatory  access  controls  for  the  GAXS. 
SECURITY  VIOLATION  is  raised  only  if  the  conditions 
for  raising  the  other  exceptions  are  not  satisfied. 

Additional  Interfaces: 

function  FTNISHJTOE  (NAME  :  in  NAMEJSTRING) 
return  CALHIDAR.TOE 
is 

NODE:  NODE  TYPE; 

RESUIT:  CALENDAR.  TOC; 
begin 

OPBN(NODE,  NAME,  (WRITE))? 

RESULT  :«  FINISH  TO®(NCCE); 

CLOSE  (NODE)? 
return  RESUIT? 
exception 

when  others  ■> 

CLOSE  (NODE)? 
raise? 

end  FINISH  TOE? 


>  \ 
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5.2.2.18  Determining  the  time  a  process  has  been  active 

function  MACHINE  JM  (NCCE  t  in  NODE  TYPE) 

return  DURA?ICN? 

Purpose: 

This  function  returns  the  value  of  the  predefined  attribute 
MACHZNEJTXME. 

Parameters: 

NODE  is  an  open  node  handle  to  the  process  node  of 

interest. 

Exceptions: 

NAMEJSRHOR  is  raised  if  the  node  is  inaccessible  or 

unobtainable. 

LOCKJERRGR  is  raised  if  the  node  is  locked  against  reading 
~  attributes. 

INIB*T_VICLMTCN  is  raised  if  the  identified  process  node  was  not 
opened  with  an  intent  establishing  the  ri<£tt  to 
read  attributes. 

SBCURITY_yiGUTIGN  is  raised  if  the  attempt  to  obtain  access  to  the 
node  identified  by  NCCE  represents  a  violation 
of  the  mandatory  access  acntxols  for  the  QMS. 
SECURITY  VIOLATION  is  raised  only  if  the  conditions 
for  raising  the  other  exceptions  are  not  satisfied. 

Additional  Interfaces: 

function  MAOHNEjmc  (NAME  :  in  NAME_STRING) 
return  DURATICN  ~ 

is 

NCCE:  NCCE  TYPE; 

RESULT:  DURATION; 
begin 

OPQUNCCE,  NAME,  (WRITE)); 

RESULT  :-  MACHINE  TTMB(KECE); 

CLOSE  ( NCCE ) ; 
return  RESULT; 
exaction 

when  others  ■> 

CLOSE  (NCCE); 
raise; 

end  MACHINE  TIME? 
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5.2.2.19  Determining  the  standard  input  file 
fraction  JOB_INEUr_FIIE  return  NAMS_STRIN3; 

Purposes 

This  function  returns  a  pathname  to  the  standard  input  file  node 
defined  at  the  initiation  of  the  root  process  node  of  the  jab,  even 
if  the  current  default  input  file  for  this  process  has  been  set  to  a 
different  file. 


Parameters: 

None. 

Exceptions: 

LOCK_ERHDR  is  raised  if  the  root  process  node  is  locked  against 
reading  relationships. 

Notes: 

In  general,  this  file  will  refer  to  the  interactive  terminal  or 
batch  input  file. 


5.2.2.20  Determining  the  standard  output  file 
fraction  JOB_amVT_FILE  return  NAMEJSTRXNS; 

Purpose: 

This  function  returns  a  pathname  to  the  standard  output  file  node 
defined  at  the  initiation  of  the  root  process  node  of  the  job,  even 
if  the  current  default  output  file  for  this  process  has  been  set  to 
a  different  file. 

Parameters: 

None. 

Exceptions: 

LOCK_ERROR  is  raised  if  the  root  process  node  is  locked  against 
reading  relationships. 

Notes: 

In  general,  this  file  will  refer  to  the  interactive  terminal  or 
batch  error  messages  file. 


5.3  CMS  Input /output 


Support  for  all  kinds  of  files  are  provided  by  the 

packages  CAIS_IO  OCOTRCL  and  CMS  10  B039TICNS.  Additionally,  each  of 
the  different  lile  kinds  is  'farther  supported  by  a  set  of  packages. 
Secondary  storage  files  are  further  supported  by  the  packages 
CMS_SBQUEOTIAL_IO,  (MS_DIRBCT_IO,  and  CMS_TEXT_IO.  Queue  files  are 
further  supported  by  the  packages  CMS_SBQUOJTIAL_IO  and  CAIS_TEXT_IO . 
Terminal  files  are  further  supported  by  thaTpeckages  CMS  TEXT~IO, 
CMS_SCHCU._TEFMnJAL,  CMSJPAGEJTERMINAL,  and  CMS_PCPM_TESMMUL . 

Magnetic  tape  drive  files-  are-  further  supported  by  the  packages 
CMS_SEX3UEOTIAL_I0,  CMS  TEXT_IO,  and  CAISJ«3NETTC  TAPE.  The  file 

kinds  and  their  associate?  support  packages  are  summarized  in  Table  IX. 


TABLE  IX.  Input/Ouitpuit  Packages  for  File  Kinds 


Implementations  of  the  packages  SEXXJDSRTALJUO,  DIKBCT_IO,  and  TEXT_IO 
specified  in  [UM]  that  operate  upon  CAIS  files  are  to  — be  constructed 
such  that  the  functionality  of  each  subprogram  in  the  respective  CMS 
packages  CAIS_SECUQ7XTAL__I0,  CAIS_DIRBCT_IO ,  and  GAIS_TEXT_IO  is  the 
same  when  the  default  FORM  peracneter  is  used  in  the  corresponding  CAIS 
CREATE  procedures. 

Secondary  storage  files  may  be  created  by  use  of  the  CREATE  procedures 
specified  in  the  packages  CAISjSBQUairiAL  10,  CMS_DIRECT_IO,  and 
CAIS  TEXT  10.  CXaeue  files  nay  be  create?  by  use  of  the  CREATE 
procedures  in  the  packages  CMS  SEQUENTIAL  10  and  GAIS_TEXT  10. 
Interfaces  must  be  provided  outside  the  CMS  for  the  creation  of 
terminal  files  and  magnetic  tape  drive  files. 

A  file  node  has  a  number  of  predefined  attributes  associated  with  it. 
The  attributes  ACCESS  METHOD,  FHE_KIM>,  QUEUE  TIPS,  and  TERMINAL  TYPE 
provide  information  about  the  contents  of  a  file  node  and  how  it  my  be 
accessed. 


PROPOSED  KTL-STO-CAIS 
31  OCT  1984 


The  predefined  values  for  the  attribute  ACCESS_MEIHOD  are  SEQUENTIAL, 
DIRECT,  and  TEXT  or  any  list  ocntoinatlon  of  theseT  The  value  of  the 
attribute  MXESS_MEXHX>  determines  the  packages  that  nay  operate  upon 
the  file.  A  value  of  SEQUENTIAL  indicates  that  the  GAIS_SBQUENTIAL_IO 
package  nay  be  used.  A  value  of  DIRECT  indicates  that  the  package 
CAIS_DIRBCT_IO  nay  be  used.  A  value  of  TEXT  indicates  that  the  package 
CAIs_TEXT_IO  and  possibly  other  packages  (depending  an  other  attribute 
values)  nay  be  used.  It  is  possible  that  a  single  file  node  may  have 
more  than  one  access  method. 

The  attribute  FTLE_KIND  denotes  the  type  of  file  that  is  represented  by 
the  contents  of  the” file  node.  The  predefined  values  for  the  attribute 
FUEJOND  are  SECONDARY  STORAGE,  QUEUE,  TERMINAL,  and  MACNCTICJEAPE.  A 
file  node  with  a  value  a?  SECONDARY  STORAGE  ar  QUEUE  may  be  operated 
upon  by  the  packages  OtfSjSEQUarciALJTO,  CAIS_DIRBCT_IO,  or 
CAIS_TEXT_IO.  A  value  of  QUEUE  permits  operations  by  the-  package 
GAIS_SEQUENTIAL_IO  or  CAIS_TEXT_IO.  A  value  of  TERMINAL  permits 
operations  by  the  package  CAIS_TEXf_IO  and  the  three  terminal  packages. 
A  value  of  MAGNETICJEAPE  permits  operations  by  the  CAIS_MAQlEnC_TAPE 
package  and  the  CMS_TEXT_IO  package.  ”  " 

The  predefined  values  for  the  attribute  QUEUE  TYPE  are  9CL0,  MIMIC,  and 
oopy. 

The  values  SCXX1,,  PAGE,  and  FORM  are  predefined  for  the  attribute 
TERMINAL  TYPE.  The  package  GAXS  TEXT  10  may  be  used  on  ary  GAIS 
tenninalT  A  value  of  SCROLL  indicates  that  the  GAIS_9CRCU,_TERMINAL 
package  may  be  ueed  an  the  file  node.  A  value  of  PAGE  indicates  that 
the  Otis  PAGEJIBMINAL  package  nay  be  used  an  the  file  node.  A  value  of 
FORM  indicates  that  the  GAIS  FORM  TTRUNAL  package  may  be  used  an  the 
file  node. 

A  file  node  with  a  QUEUEJKPE  of  oopy  or  mimic  will  have  the 
relationship  of  the  predefined  relation  ASSOCIATE  to  the  file  node  with 
which  it  is  associated. 

A  file  node  for  a  terminal  will  have  a  value  of  TEXT  for  the  attribute 
ACC3SS_MEMCD  and  a  value  of  TERMINAL  for  the  attribute  FUE  KIND  In 
addition,  the  attribute  TERMDJALJTYPE  will  have  one  (or  more)  of  the 
values  SCROLL,  PAGE,  or  FORM. 

A  fiLle  node  for  a  magnetic  tape  drive  has  a  value  of  MAGNEflCJTAPE  for 
the  attribute  FILE  KIND  and  a  value  of  TEXT  for  the  attribute 
ACCESS JEIKX).  The  packages  CAIS  TEXT  10  and  CAIS_TAPE_IO  may  be  ueed 
for  operating  an  a  magnetic  turn  drive  file.  ” 
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5.3.1  Package  CAIS_DIRECT_IO 

This  package  provides  facilities  for  direct  access  input  and  output  to 
G&IS  files  caiparable  to  those  ils  scribed  in  the  DIRBCT_IO  package  of 
[IiW].  Files  written  with  the  CAIS_DIHECT_IO  are  also  readable  by 
CAIS_SEJQUENITAL_IO ,  if  the  data  types  are  the  mbs. 

the  package  specification  and  seunnti.cs  of  the  OdS  DIRECT  10  is 
oonparable  to  that  of  the  [LEM]  package  DIRBCT_IO.  The  following 
sections  dencnstrate  the  specifications  and  sanantics  that  differ. 


5. 3. 1.1  Types,  subtypes,  constants,  and  exceptions 

subtype  FILE_TYPE  is  CMSJCOjXMrRX.FII^jrePE; 

subtype  FTLEJCCE  is  C3US_10JXNTRCL .  FILEJNECE  ; 

IN_ETI£  x  aonstant  FUEJCCE  INJFILE; 

HCOT_FII£  x  constant  FUjQCDB  x*  INOOT_FILE; 

OJTJTLE  X  aonstant  FXU0OCE  :■  OOT_E®LE; 

FILE_TFPE  is  used  as  a  handle  for  all  direct  input  and  output 
operations.  FILE  MGCE  indicates  the  intent  i^acn  accessing  the  direct 
input  or  output  file. 


5. 3. 1.2  Creating  a  direct  I/O  file 

procedure  CKEME(FILE  :  in  out  FII£_TFPE; 

BASE  x  in  MXE_TFPE» 

KEF  x  in  RBUUnCHBBIP  KEF  x-  IATEST  KEF; 

RELMTCN  x  in  REUKTICH  NMf  x»  EEFWJLT_F&ATICN? 

MODE  x  in  HLEjaX  x-  DBOT_PILE; 

FORM  x  in  LIOTJITPE  s-  EMPTF_LIOT; 

XCIUBDIISt  in  LIST  TYPE  xa  EMPTF_LIST? 

ACCESS  OCNTHCLi  in  ~  TORMSTRING  7» 

LEVEL*-  in  FORM  STRING  7- 
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Purposet 

This  procedure  creates  a  file  and  its  file  node;  each  element  of 
the  file  is  directly  addressable  by  an  index.  The  attribute 
PCCESSJGHXD  is  assigned  the  value  "(DIRECT,  SEQUENTIAL)"  as  part 
of  the- creation. 

The  contents  of  FORM  have  the  syntax  of  a  LIST  TVPE  (Section  5.4). 
The  FORM  parameter  is  used  to  provide  file  characteristics 
concerning  the  creation  of  the  file.  The  predefined  file 
characteristic  SIZE  nay  be  used  to  specify  an  approximation  to  the 
nurioer  of  STORAGEJJNITs  that  should  be  writable  to  the  file.  The 
SIZE  characteristic- ia  specified  as  "(SIZE  m>  n)“,  where  "n"  is  any 
NATURAL  mutter. 

The  ATTRIBUTES  parameter  defines  and  provides  initial  values  for 
attributes  of  the  node  (for  the  use  of  values  of  type  LISTJTYPE,  see 
Section  5. 4. 3. 2  CXBJJSTJJITLITIES).  The  AXESSjXNlTCL  parameter 
specifies  initial  access  control  information  to  be  established  for 
the  created  node. 

The  LEVEL  parameter  specifies  the  security  level  at  Which  the  file 
node  is  to  be  created. 

The  value  of  the  attribute  FH£_KH1D  for  the  file  node  will  be 
SBOCNDAEOf  STORAGE. 


Parameters! 

FILE 

BASE 


KEF 


RELATION 


is  a  file  handle,  initially  closed,  to  be  opened. 

is  an  open  handle  to  the  node  vAiich  will  be  the 
source  of  the  primary  relationship  to  the  new 
node. 

is  the  relationship  key  of  the  primary 
relationship  to  be  created. 

is  the  relation  name  of  the  primary  relationship 
to  be  created. 


MXE  indicates  the  mode  of  the  file. 

FORM  indicates  file  characteristics. 


ATTRIBUTES  defines  initial  values  for  attributes  in  the 

newly  created  node. 


AGCESSJXNTROL  defines  the  initial  access  control  information 
associated  with  the  created  node. 


LEVQ,  defines  the  classification  label  for  the  created 

node. 


Exceptions! 
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NMCJSRROR  is  raised  if  a  node  already  exists  for  the  node 
identification  given,  if  the  node  identification  is 
syntactically  illegal,  or  if  any  group  node  specified 
in  the  value  of  the  ACCESSjXtriRCL  parameter  is 
unobtainable. 

STAOTS_ERROR  is  raised  if  BASE  is  not  an  open  node  handle,  or  if 
FILE  is  an  open  file  handle  prior  to  the  call. 

USE_ERROR  is  raised  if  the  AOCESSJXMTRCL  or  LEVEL  parameters  do 
not  adhere  to  the  required  syntax  or  if  the  ATTRIBUTES 
parameter  contains  references  to  predefined  attributes 
not  modifiable  by  the  user. 

IOTBIT_VIOLATICW  is  raised  if  BASE  was  not  opened  with  an  intent 
establishing  the  ri$it  to  append  relationships. 

SECURTTY_VI<XATICN  is  raised  if  the  operation  represents  a  violation 
of  mandatory  security  rules.  SECURITY  VIOLATION  is 
raised  only  if  the  conditions  for  otKar  exceptions 
are  not  present. 

Additional  Interfaces 

procedure  CREATE  (FILE  :  in  out  FTLEJIYPE; 

tsue  :  in  NAMETsTRING; 

MODE  :  in  FILE" MODE  x«  m0UT_FH£; 

FORM  j  in  LIST" TYPE  :«  QCTYLICT; 

ATTRIBUTES:  in  OSPJKPE  :-  EMPTY  LIST; 

ACCESS  OCNTHCL:  in  "  EDRM_SnONG  T«  ""? 

LEVEL:-  in  FORM  STRING  *»  "") 
is 

BASE  :  NCDE_TYPE; 
begin 

OPQI(BASE,  BASE  PATH  (NAME),  (  APPQ*D_HELATICKSHIPS )  )  ; 
CREATE(FILE,  BASE,  LAST  KEY(NAME),  LAST  RELATICN(NA»e), 

MXE,  FORM,  ATTRIBUTES,  ACaSSJXNTRCL,  LEVEL); 
aCSE(BASE); 
exception 

when  others  ■» 

CLOSE  (FILE); 

OOSE(BASE); 
end  CREATE; 


n  m 
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5. 3. 1.3  Opening  a  direct  I/O  file 

procedure  CPEN(FILE  t  in  out  FILE  TOPE; 

NOCE  t  in  NXEJKPE; 

MOCE  t  in  FUZJCCE  !•  QCOT_FTLE) ; 

Purpoeei 

This  procedure  open*  a  handle  on  a  file;  each  element  of  the  file 
is  directly  addressable  by  an  index. 

Parameters; 

is  a  file  handle,  initially  closed,  to  be  opened, 
is  an  open  handle  to  the  file  node, 
indicates  the  mode  of  the  file. 


is  raised  if  the  attribute  AOCESSJETHOD  of  the  file 
node  does  not  have  the  value  DIRECT  cr  the  element 
type  of  the  file  does  not  correspond  with  the  element 
type  of  this  instantiation  of  the  CAIS_DIHECT_IO 
package. 


STATUS JQWOR  is  raised  if  the  FILE  is  already  open  prior  to  the 

call  on  OPEN. 

INTQfr_VKXATICN  is  raised  if  MODE  has  not  bean  opened  with  an  intent 
establishing  the  right  associated  with  the  MOCE 
specified,  as  explained  in  Table  VIII. 

Additional  Interface: 

procedure  OPB?(FILE  :  in  out  FILE  TOPE; 

NAME  :  in  NA«_STRIN3; 

MOCE  :  in  FUE-iCCE  INCUT  FILE) 

is  “ 

NOCE  :  NCCE_TOPE; 
begin 

case  MOCE  is 

IN  FILE  -»  OPEN (NODE,  NAME,  (READ  OCNIENIS)); 

OUT  FILE  ->  OPEN (NOCE,  NAME,  (WRITE  CONTENTS)); 

INCUT  FILE  *>CPEN(NQCE,NM6,  (FEADJOCNTENTS, WRITE  CONTENTS) ) ; 
APPEND  FILE  ->  OPEN(NQCB,  NAME,  (APPEND  CONTENTS)!; 
end  case;  ~ 

OPBI(FIL£,  NCCE,  MOCE) 

CLOSE  (NODE); 
exception 

when  others  •> 

CLOSE (FILE); 

CLOSE  (NCCE); 
and  OPEN; 
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Notes: 

The  effects  of  closing  an  open  file  node  handle  on  the  open  file 
handle  to  the  contents  of  this  node  are  implicitly  defined.  In 
particular,  no  assumption  can  be  made  about  the  access 
synchronization  provided  by  the  node  model. 


5.3.2  Package  CAIS_SEaUEOTIAL_IO 

This  package  provides  facilities  for  sequentially  accessing  data 
elements  in  GAIS  files.  These  facilities  are  ocnparahle  to  those 
described  in  the  SEX3UEOTIAL_IO  package  of  [LRM]. 

The  package  specification  and  semantics  of  the  CAIS_SEQUEOTIAL  lO  is 
comparable  to  that  of  the  [LRM]  package  SBQUEOTIAL_IO.  The  following 
sections  demonstrate  the  specifications  and  semantics  that  differ. 


5. 3. 2.1  types,  subtypes,  constants,  and  exceptions 
subtype  FUEJTYPE  is  CAIS_IO_QCNrHCL . FTIE_TYPE ; 


subtype  FILE_MX£  is  CMS_IO_CEtmCL .  FH£_MXE  ; 


IN_FHE  :  oonstant  FILE  MODE  :«  IN_FHE; 

INCUT  FU£  :  oonstant  FH£_MXE  :«  HOJT_FII£; 

OUT  F&£  :  constant  F HZ- MODE  :-  OOT_FILEr 

APFEND_FILE  :  constant  FUEJCCE  :■  APPQJDJETIE; 

FILE_TYPE  is  used  as  a  handle  for  all  sequential  input  and  output 
operations.  FHE_MXE  indicates  the  intent  upon  accessing  the 
sequential  input  or  output  file.  A  mode  of  APPEND_FH£  causes  any 
elements  that  are  written  to  the  specif ied  file  to  be  appended  to  the 
elements  that  are  already  in  the.  file. 


5. 3. 2. 2  Creating  a  sequential  I/O  file 


procedure  CREATE (FILE 
BASE 
KEY* 

RELATION 

MODE 

FORM 


in  out  FILE  TYPE; 


NODE  TYPE; 

RELATIONSHIP  KEY  :•  LATEST  KEY; 
RELATICN_NAME  DEFAULT  fSLATICN; 
FILE  MXE  :-  INOOT_FILE;- 
LISTJTYPE  :«  EMPTY  LIST; 
ATTRIBUTES:  in  LIST-" TYPE  :■  EMPTY1- LIST; 

ACCESS  CONTROL:  in  ~  FORM  STRING  7- 
LEVEL:-  in  FORM  STRING  7-  ""); 


in 

in 

in 

in 

in 


Purpose: 

This  procedure  creates  a  file  and  its  file  node;  each  element  of 
the  file  is  sequentially  accessible.  The  attribute  MXESS_MEXHOD  is 
assigned  the  value  "(SEQUENTIAL)"  as  part  of  the  creation.- 
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The  contents  of  FORM  have  the  syntax  of  a  LIST  TYPE  (Section  5.4). 
The  FORM  parameter  is  used  to  provide  file  characteristics 
concerning  the  creation  of  the  file.  The  predefined  file 
characteristic  SIZE  may  be  used  to  specify  an  approximation  to  the 
nunber  of  STORASJJNITs  that  should  be  writable  to  the  file.  The 
SIZE  characteristic  is  specified  as  ‘(SIZE  ■>  n) ' ,  where  'n*  is  any 
NATURAL  nunber. 

The  ATTRIBUTES  parameter  defines  and  provides  initial  values  for 
attributes  of  the  node  (far  the  use  of  values  of  type  LISTJTXPE,  see 
Section  5. 4.3. 2  CAIS JLISTJJITLITTES ) .  The  PCCESSJXJtmOL  parameter 
specifies  initial  access  control  information  to  be  established  far 
the  created  node. 

The  LEVEL  parameter  specifies  the  security  level  at  which  the  file 
node  is  to  be  created. 

The  default  value  for  the  attribute  FH£_KIND  for  the  file  node  will 
be  SEOONDAR?JSTORAGE.  The  default  value  nmy  be  overriddan  by 
explicitly  specifying  a  value  of  QUEUE  in  the  FORM  parameter  (e.g. 
'  (FILE  KIND  •»  QUEUE) 1 ) .  The  default  QUEUE_TXPE  is  a  solo  queue. 

Parameters: 

FILE 

BASE 


REST 


RELATION 


kxe 

FORM 

ATTRIBUTES 


ACCESS  OCNTROL 


LEVEL 


Exceptions: 
NAME  ERROR 


is  a  file  handle,  initially  closed,  to  be  opened. 

is  an  open  handle  to  the  node  vfoich  will  be  the 
source  of  the  primary  relationship  to  the  new  node. 

is  the  relationship  key  of  the  primary  relationship 
to  be  created. 

is  the  relation  name  of  the  primary  relationship  to 
be  created. 

indicates  the  mode  of  the  file, 
indicates  file  characteristics . 

defines  initial  values  for  attributes  in  the  newly 
created  node. 

defines  the  initial  access  control  information 
associated  with  the  created  node. 

defines  the  classification  label  far  the  created 
node. 


is  raised  if  a  node  already  exists  for  the  node 
identification  given,  if  the  node  identification  is 
syntactically  illegal,  or  if,  far  the  parent  node  of 
the  node  to  be  created  or  any  group  node  specified  in 
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the  given  access  list,  the  node  is  unobtainable. 

SEATUS_EHRCR  is  raised  if  BASE  is  not  an  open  node  handle  or  if 
FILE  is  an  open  file  handle  prior  to  the  call. 

INrarr_yiC£ATICN  is  raised  if  BASE  was  not  opened  with  an  intent 
establishing  the  right  to  append  relationships. 

SECURTTM/ICLATICN  is  raised  if  the  operation  represents  a  violation 
of  mandatory  security  rules.  SEXTJRITYJVXaUCTICN  is 
raised  only  if  the  conditions  for  other  exceptions 
are  not  present. 

Additional  Interface: 

with  CAIS_NCCE_>®NAGEMENr  ? 

use  CAIS JTCCE JMWSBeir ; 

procedure  CREATE  (FILE  :  in  out  FILEJIYPE; 

NAME  :  in  NAfflfSTRlNG; 

MODE  :  in  FUE  MQCB  »«  rtXVT  FUE; 

FCSM  :  in  &SS  TYPE  :«  ElfeW  LIST; 
ATTRIBUTES:  in  LIST* POTE  :«  aCTY_LICT; 

AOCESSjXNTRCt:  in  “  FORM  STRING  7« 

LEVEL:-  in  roBM_STRING  7-  "") 
is 

BASE  :  NCDE_TOTE; 
begin 

OPEN  (BASE,  BASE  PATH  (NAME),  (APPQ©_RELAT1CKEHIPS)  )  ; 

CREATE  (FILE,  BASE,  LAST  KEY  (NAME),  LAOT_RELATICN  ( NAME  ) , 

MODE,  FORM,  ATTRIBUTES,  ACCESS  OOIIRCL,  LEVEL); 
CLOSE(BASE); 
exception 

when  others  «> 

CLOSE  (FILE) ; 

CLOSE (BASE); 
end  CREATE; 


5. 3. 2. 3  Opening  a  sequential  I/O  file 

procedure  OPEN (FILE  :  in  out  FUEJCIND; 

NODE  :  in  NDDE_TOTE; 

MCDB  :  in  FHJE_tOCE) ; 

Purpose: 

This  procedure  opens  a  handle  on  a  file;  each  element  of  the  file 
is  sequentially  accessible. 

Parameters: 

FILE  is  a  file  handle,  initially  closed,  to  be  opened. 

NOCE  is  an  open  handle  to  a  base  node  for  node 
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Identification. 

MOCE  indicates  the  node  for  accessing  the  file. 


Exceptions: 

U5EJ3RRQR  is  raised  if  the  attribute  AOCESS_METHOO  of  the  file 

node  does  not  have  the  value  SEQUENTIAL  or  the 
element  type  of  the  file  does  not  correspond  with  the 
element  type  of  this  instantiation  of  the 

CMS  SEQUENTIAL  10  package. 


STATUS_ERRCR  is  raised  if  the  FILE  is  already  open  prior  to  the 
call  on  OPEN. 

nnTNT_VICLATICN  is  raised  if  NODE  was  not  opened  with  an  intent 
establishing  the  right  associated  with  the  MODE 
specified,  as  explained  in  Table  VIII. 


Additional  Interface: 

procedure  QPEN(FHE  :  in  out  FIL£_T¥PE; 

NAME  :  in  NA*E~STRING; 

MOCE  :  in  FXLE*MQCE  j-HJOUT  FILE); 

is 

NODE  :  NCDEjrXFE; 
begin 

case  MODE  is 

IN_FHE  ->  OPEN(NOOE,  NMC,  (HEADJXNTENIS) ) ; 

CUT  FUZ  ->  OPEN(NDCE,  NAM!,  ( WRITE JXNITNTS)  ); 

INCUT  FILE  »OPEN(NCOE,NAtC,  (READ  CCNTENTS, WRITE  CONTENTS)); 
APPDtf)_FILE  ■>  OPEN  (NODE,  NAME,  (AFPENDJXNTENTS)T; 
end  case;  " 

OPEN  (FILE,  NODE,  MXE) 

CLOSE  (NODE); 
exception 

When  others  ■> 

OOSE(FILE); 

CLOSE  (NODE); 
end  (SEN; 
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5.3.3  Package  CMS_TEXT_IO 

this  padcage  provides  flicil  (ties  for  ths  input  and  output  of  textual 
data  to  GAIS  files,  thane  facilities  are  ocsparable  to  those  specified 
in  the  package  TEXT  10  in  [L8M].  the  fallowing  sections  are  those  that 
differ  from  the  specifications  in  [UK]. 


5.3. 3.1  Type*'  sttypee,  constants,  and  exceptions 
subtype  FILE_TOT  is  CMS_IO_aCNnCL .  FHE_TOT ; 


subtype  FTIE_MOCE  is  CAIS_IOjXNTHGL.riLE_MXE; 

IN  FILE  t  constant  FILE  M3CE  tm  IN  FILE; 

INDOT  FOE  x  aonstant  FHEJCXS  *-  3M0OT  FILE; 
nn-jrfsp.  t  constant  FIXE- MCCE  :■  QOT_A2; 

APEBDJFHE  s  aonstant  FILE- MCCE  i«  AFEBDjniE; 

FUEJTOT  is  used  as  a  handle  far  all  text  input  and  output  operations. 
FHE_M0CE  indicates  the  intent  upon  aoceeeing  the  text  input  or  output 
file.  A  node  of  APPQDJFXIE  naueea  any  text  written  to  the  specified 
file  to  be  appended  to  the  text  that  is  already  in  the  file. 


5. 3. 3. 2  Creating  a  text  I/O  file 


procedure  CREME  (FILE  :  in  out 

BASE  i  in 

REF  s  in 

rbation  t  in 

MXE  :  in 

FOM  X  in 


FIXE  TOT; 

NODE- TOT; 

FBXFICNSBZP  REST  t-  LMEST  KEY; 
RELATION  NNB  t»  O0MULTJREXATICN; 
FLLEJCEE  i-  nBOTJPUE;- 
LIST  TOT  EMPTY  LIST; 


XRRXBOTESx  in  LIST  TXPE  i»  EMPTY  LIST; 
ACCESS  OCNTRQLx  in  “  FORM  STRING  x« 
LEVELx-  in  FORM  SIRING  7-  "") 


Purpossx 

This  procedure  creates  a  file  and  its  file  node;  the  file  is 
textual,  the  attribute  ACXZSSjdBQD  is  assigned  the  value  “(TEXT)" 
as  part  of  the  creation. 


the  contents  of  FORM  have  the  syntax  of  a  LISTJTOT  (Section  5.4). 
the  FORM  parameter  is  used  to  provide  file  characteristics 
concerning  the  creation  of  the  external  file,  the  predefined  file 
characteristic  SIZE  my  be  ueed  to  specify  an  approximation  to  the 
nunbar  of  STORAffiJMTs  that  diould  be  writable  to  the  file,  the 
SIZE  characteristic- is  specified  as  '  (SIS  ■>  n) ' ,  there  'n*  is  any 
twnjRAL  nnber. 

the  X2TRIBOTES  parameter  defines  and  provides  initial  values  for 
attributes  of  the  node  (far  the  use  of  values  of  type  LIST  TOT,  see 
Section  5.4.3. 2  CMS  LIST  OTILITIES).  the  ACCESS  CONTROL  parameter 
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initial  access  ocntrol  Information  to  be  established  foe 
th*  created  nod*. 

Th*  LEVS,  paraatar  specifies  th*  eeciari.ty  l*v*l  at  whidh  th*  fil* 
nod*  i*  to  b*  created. 


The  default  value  for  the  attribute  FTLEJCQD  is  SEX»«)AR*J9iaRH3E. 
th*  default  wlue  nay  b*  overridden  by  explicitly  specifying  a  value 
of  QUEUE,  THBGNAL  or  MCKETIC  TAPE  in  the  POSH  parameter  (e.g., 
"(FUEJOHD  -*  QUEUE)1).  Specifying  the  PTIZJCM3  as  OUEUE  create* 
a  solo  queue.  “ 


PILE 


rest 

RELATION 


is  a  file  handle,  initially  dosed,  to  be  opened. 

is  an  open  handle  to  the  node  Which  will  be  the 
source  of  the  primary  relationship  to  th*  new  node. 

is  the  relationship  key  of  the  primary  relationship 
to  be  created. 

is  the  relation  name  of  the  primary  relationship  to 
be  created. 


MODE 

FORM 

ATTRIBUTES 

ACCESSJXMIRCL 

LEVEL 


indicatee  the  mode  of  th*  file, 
indicates  file  characteristics. 

defines  initial  values  for  attributes  in  the  newly 
crested  node. 

defines  the  initial  access  control  information 
associated  with  the  crested  node. 

defines  the  classification  label  for  the  created 
node. 


Exceptions: 

mc_ERRQR  is  raised  if  a  node  already  exists  for  the  node 

“  identification  given,  if  the  node  identification  is 

syntactically  illegal,  or  if  any  group  node 
specified  in  the  value  of  the  AOCESSJXtURCL 
parameter  is  unobtainable. 


STMXUSJ9RRGR  is  raised  if  BASE  is  not  an  open  node  handle,  or  if 

~  FILE  is  an  open  fils  handle  prior  to  the  call. 

UBEJBOCR  is  raised  if  the  ACCESS JXOTRCL  or  LEVEL  parameter* 

do  not  adhere  to  this  required  syntax  or  if  the 
ACTRIBUIES  parameter  oentains  references  to 
predefined  attributes  not  modifiable  by  the  user. 
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QRB7T  VIOLATION  is  raised  if  BASE  VU  not  opened  with  an  intent 
establishing  tits  right  to  append  relationships . 

SECURITY  VIOLATION  is  raised  if  the  operation  represents  a  violation 
”  of  mandatory  security  rules.  SECURITY  VIOLATION  is 

raised  only  if  the  conditions  for  otfier  exceptions 
are  not  present. 

Additional  Interface: 

procedure  CREATE  (FILE  :  in  out  FUETYPE; 

NAM  t  in  NAMEJSnTOS; 

MXE  :  in  FZIE~MGOE  :«  INCUT  FILE; 

FORM  :  in  ElST  TYPE  *-  Efl?TY  LIST; 
ATTRIBUTES:  in  LIST- RPE  *»  EMPTY~LIST? 

ACCESS  OamCLt  in  ~  FORM  STRING  j- 
LEVEL:-  in  FORM  STRING  7-  "") 
is 

BASE  :  NOOSJRPE; 
begin 

OPEN  (BASE,  BASE  PATH  (NAME),  (APPDD  RSOATICKSHIPS) ) ; 

CREME  (FILE,  BAM,  LAST  KEYNAME),  £AST_RnAnCN(tWe) , 

MODE,  FORM,  ATTRIBUTES,  ACCESS  OCNIRCL,  IEVH,); 

CLOSE (BASE);  “ 

exception 

when  others  ■> 

CLOSE  (FILE)  ; 

CXOGE(BASE); 
end  CREATE; 


5. 3. 3. 3  Opening  a  text  I/O  file 

procedure  OPEN(FH£  :  in  out  FUE  TYPE; 

NODE  i  in  NCCE~ TYPE; 

MODE  :  in  FUEJCXE  :«  a*XJr_FHE); 

Purpose: 

This  procedure  opens  a  handle  on  a  file  that  has  textual  contents. 
Parameters: 

FUE  is  a  file  handle,  initially  closed,  to  be  opened. 

NODE  is  an  open  handle  to  the  file  node. 

MODE  indicates  the  mode  of  the  file. 


Exceptions: 

USE_ERRDR  is  raised  if  the  attribute  MXESSJCTHOO  of  the  file 

node  does  not  have  the  value  TBCT  or  the  element  type 
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of  the  file  dow  not  oorraepcnd  with  the  alont  type 
of  this  instantiation  of  the  CMS  TBCT  10  package. 


STATUS  ERROR  ia  raised  if  the  FUE  ia  already  open  prior  to  the 
call  an  OPEN. 

MIENT  VKXATZCN  ia  raiaad  if  SGCE  has  not  bean  opened  with  an  intent 
~  establishing  the  ri^rt  associated  with  the  intent 

associated  with  the  MDCB  ■pacified,  as  explained  in 
Table  VIII. 


Additional  Interface! 

procedure  OPEN(FILE  t  in  out  FUE  TYPE; 

CMC  t  in  HAMTsTKOC; 

mcce  t  in  rnzjax  «-ncwr_PiLE); 

ia  - 

NCOS  t  NOCEJKFE; 
begin  “ 

case  MOCK  is 

IN_PTLE  ->  OP®(NCCE,  SMC,  (HEAD  OCNXBrrS)); 

Off  FILE  ->  OPEN (NODE,  EMC,  (100%  OOERQRS)); 

wan  nu  -xxtn(mcce,hnc,  (read  aamans.wrsE  caroms) ) ; 
appenE  fue  ->  open(ngce,  nmc,  (aPpqo  awrons)T; 

end  case;” 

OPEN (FUE,  NODE,  MODE) 

CLOSE  (NODE); 
exception 

when  others  ■> 

CLOSE  (FUE); 

CLOSE(NOCE); 
end  apart 


5. 3. 3.4  Reading  from  a  file 
procedure  GBT(...); 


Purpose! 

These  procedures  reed  characters  from  the  ■pacified  text  file. 

For  all  wluas  of  the  attribute  FUE  KHD  only  reading  of  the 
printable  ASCII  characters  plus  the  feat  effectors  Galled 
horisontal  tabulation,  vertical  tabulation,  carriage  return,  line 
feed,  and  form  feed  are  defined.  All  of  the  printable  characters 
plus  the  horiaontal  tabulation  and  vertical  tabulation  characters 
nay  be  read  aa  characters.  The  characters  carriage  return  and  line 
feed  are  to  be  treated  as  line  taminstars  Whether  encountered 
singly  ar  together  (i.e.  CR,  IE,  CHE,  and  LECR  are  line 
terminators).  The  character  form  feed  ia  to  be  treated  aa  tha  page 
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terainatcr. 

Vtai  tot  is  being  r«ad  from  a  file  node  whose  attribute  FUE  KHD 
las  tha  valuB  TEFMZNAL,  it  ia  expected  that  aoat  ifil  — ntaBone 
will  provide  £adlitiaa  far  editing  the  input  entered  toy  the  ueer 
before  nafcing  the  characters  available  to  a  program  far  seeding. 


5.3. 3. 5  Setting  the  input  file 

procedure  SET_INPOT(FIIE  i  in  FHJE_TXPE); 


Purposes 

In  to  the  specified  in  the  ClEM],  tee  relation 
‘CURRaJTJCNPUT  of  the  calling  prooees  is  aet  to  refer  to  tee  node 
associated  with  FILE. 


FILE 


Exceptions t 
MXEERHOR 

STATUS  ERROR 


ia  an  open  file  handle. 

is  raised  if  tee  node  of  FHZ  is  CUT _FHZ  or 
APPn®_FH£. 

ia  raised  if  FUE  is  not  open. 


5. 3. 3. 6  Setting  the  output  file 

procedure  SET_OUT£Vr(FIIE  s  in  FUEjnPE)? 

Purposes 

In  addition  to  tee  sasmixtics  specified  in  the  [U*0»  tee  relation 
’CURHQrcMXTTPOT  of  the  calling  proceee  is  aet  to  refer  to  tee  node 
associatad  with  FILE. 

Parameters  s 

FILE  is  an  open  file  handle. 

Exceptions i 

MOCE_ERROR  is  raised  if  the  node  of  FUE  is  IN  FUE. 

STMUS  ERROR  is  raised  if  FUE  is  not  open. 
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5. 3. 3.7  Setting  the  error  £ile 

procedure  9rr_HOGR(FILE  i  in  FHE_TYPE); 

Pucpaeei 

Each  QMS  prooeee  has  an  error  file  Vf)cn  intitiation.  This 
procedure  provides  an  qpsn  file  handle  to  be  used  for  current  error 
output.  In  addition,  the  relation  ' CURSOR1  ERROR  of  the  calling 
procedure  is  set  to  refer  to  tha  node  associated  with  FILE. 

Parameters! 

FILE  is  the  desired  default  file. 

Exceptions: 

MDOE_QSOR  is  raised  if  the  node  of  FILE  is  IN_FTLZ. 

STMTJS_EKCR  is  raised  if  FH£  is  not  open. 


5.3. 3. 8  Determining  the  standard  error  file 
function  3TMCARD_ERRCR  return  FIUSJHPE? 

Purposes 

this  fmetion  returns  a  handle  on  error  output  file  that  was  set  at 
the  etart  of  program  execution. 

Exceptiones  none 


5. 3. 3. 9  Determining  the  current  error  file 
function  CURRHRMSRCR  return  FLUEJONDr 
Purposes 

This  Auction  returns  tha  current  error  output  file,  which  is  either 
the  standard  error  file  or  the  file  specified  in  the  meet  recant 
invocation  of  SETJERRCR. 

Parameters:  none 


Exceptions:  none 
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5.3.4  Package  C>IS_IO_Efl3mCHS 

This  padtage  provides  the  definitions  for  all  eoceptions  generated  fay 
the  input  and  output  packages.  These  definitions  are  acnparable  to 
those  specified  in  the  package  10  EKZPTXCNB  in  CUM]. 


5.3.5  Padcage  CAIS_IOJXNIRCL 

This  package  defines  facilities  that  nay  be  used  to  modify  and/or  query 
the  functionality  of  CMS  files. 

The  package  provides  for  association  of  input  and  output  tart  files  with 
an  output  logging  fils.  It  also  provides  facilities  for  forcing  data 
from  an  internal  file  to  its  associated  external  file. 


5. 3. 5.1  Types,  subtypes,  aonstanta,  and  exceptions 

type  (HARACIERJlsr  is  array(CBMncXBR)  of  BOOLEAN; 

type  FIUBJtXE  is  (XNJILE,  XNOUTjnZN,  COT_PHE,  APPDBJTLB); 

type  FH£_TYPE  is  l  iari tad  private; 

type  EtlCTKN_KEy_pE3CRlPTOR  is  limited  private; 

type  POSmCKTXPE  is 
record 

RON  t  NATURAL? 

<XUMf  i  NATURAL; 
end  rsoord; 

CHARACTER _LIST  provides  information  ooncetning  the  characters  that  can 
be  obtained  during  a  GET  operation.  PIZEMCCE  indicates  the  type  of 
operations  that  are  to  be  permitted  on  a  file.  Analogously  to  [LRM] 
type  FIUEJHEB  and  the  CAIS  type  NODE  TYPE,  the  CAIS  provides  a  type 
ETLE_TYPE  whose  values  axe  intemeT  references  to  Ma  external  files. 
ETLE_TYPE  is  used  for  controlling  the  opsratione  of  all  files. 
PUI^CNJCEYJQESailPTCfl  is  used  to  determine  the  function  keys  entered 
from  a  terminal.  P061T1CN_TYEE  is  used  to  specify  a  position  an  a 
terminal. 
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5. 3.5.2  Obtaining  an  open  nod*  handla  team  a  file  handle 

pcooedure  MXE(FIL£  t  in  FZLE  TOPE; 

NCCE  <  in  out  *nf«FE); 


Purpoeei 

This  fraction  returns  an 
with  a  file. 


node  handle  for  the  node  associated 


FILE  is  an  open  file  handle. 

NODE  is  a  nods  handle,  initially  closed,  to  be  opened. 

Exoaptionst 

STATUS _ERR0R  is  raised  if  FUE  is  not  open  or  if  MODE  is  open. 


5. 3. 5. 3  Synchronizing  program  10  with  system  10 
procedure  SYCHHOU a ( FILE  t  in  out  FXX2_TOPE); 

Purposei 

This  procedure  forces  all  data  that  has  bean  written  to  the  internal 
file  FILE  to  be  trananitted  to  the  external  file  with  Which  it  is 
associated. 


Exceptions! 
USE  ERROR 


is  the  internal  file  to  be  synchronized. 


is  raised  if  FLU!  is  of  mods  IN  FILE. 


9TKIUS_ERRQR  is  raised  if  FUE  is  not  open. 


5.3. 5.4  Establishing  a  LOG  file 

procedure  SET  LOG  (FILE  «  in  out  FILE  TOPE; 

LOGJTLE  i  in  FIIEJRPE); 

Purposes 

This  proosdure  establishes  a  log  fils  for  FUE  (a  fils  of  node 
INCUT 'FUE  or  OUT_FHE).  All  elements  written  to  internal  fils  FUE 
are  aHra  written  to  LOG  FOE. 


LOG  FUE 


is  the  file  vftiidi  is  to  have  a  log  file, 
is  the  file  to  which  the  log  should  be  written. 
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MCCE  ERROR  is  raised  if  the  sods  of  either  P HZ  or  1X36  FILE  is 

IHPXXE. 

USE_ERRCR  is  raised  if  FXIZ  and  LOG_JTIE  do  not  haws  tha  sana 

values  for  tha  attribute  RoBfesSJCHOP  or  do  not  have 
gcepetihle  elements  ( ispls—ntatioo-dsfinBd) . 


STATUS  ERROR  is  raised  if  LOG  PILE  is  not  open. 


5. 3. 5. 5  Knowing  a  log  file 

procedure  CIEAR_LOG_FIIE ( FILE  s  in  PHEJIYPE); 

Purpoeet 

This  procedure  moves  the  log  file  established  for  FILE. 


FILE 


USE_ERBDR 
STATUS  ERROR 


is  an  open  file  handle  that  has  a  log  file. 


is  raised  if  FUE  does  not  have  a  log  file, 
is  raised  if  PIIE  is  not  open. 


5. 3. 5. 6  Determining  vtoethsr  logging  is  specified 

function  LOGGING  (FILE  :  in  FUE  TIPS) 
return  BOOLEAN ; 

Purpaeex 

This  function  returns  TRUE  if  FILE  has  a  log  file;  otherwise  FALSE. 
Parameters! 

FUE  is  an  open  file  handle. 

Exceptions: 

STATUS  ERROR  is  raised  if  FILE  is  not  CPQf. 
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5. 3. 5.7  Determining  the  log  file 

function  LOG_FHZ  (FIZZ  :  in  FILEJKPE) 
return  raz_IOND; 

Purposes 

This  fraction  returns  the  current  logging  file  associated  with  FIZZ, 
the  file  handle  returned  is  not  open  if  not  logging. 

Parameters  s 

FUZ  is  an  open  FIZZ. 

Exceptions: 

USEJEKCR  is  raised  if  FUZ  has  no  log  file. 

STATUS  ERROR  is  raised  if  FIZZ  is  not  OPBl. 


5. 3. 5.8  Determining  the  file  size 

function  SIZE  (FIZZ  t  in  FnzjKPE) 
return  NATURAL; 

Purposes 

this  function  returns  the  nuntoer  of  elements  contained  in  FUZ. 
Parameters: 

FUZ  is  an  open  secondary  storage  or  queue  file. 

Exceptions: 

USE  BOOR  is  raised  if  the  file  type  of  FUZ  is  neither 

QUEUE  nor  SBCCN3AR?J3TORAGE. 

STATUS  BOOR  is  xaissd  if  FUZ  is  not  CPBI. 


5. 3. 5. 9  Setting  the  prenyl  string 

procedure  SETJTROMPT  (TERMINAL  :  in  FHZ_TXPE; 

PROMPT  t  in  SHUNS); 

Purpose: 

this  procedure  sets  prceyting  string  for  TERMINAL.  All  future 
requests  for  a  line  of  input  from  TERMINAL  will  output  prcuyl  string 
first,  the  prompting  string  and  any  echoed  input  are  also  copied  to 
the  log  file,  if  any. 

Parameters: 

URMQAL 


PROMPT 


is  an  open  terminal  handle, 
is  the  new  value  of  the  prenyl 
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Exceptions: 

USE_ERRDR  is  raised  if  the  attribute  TSMINAL_TCPE  does 

not  have  the  value  SCROLL. 

STAIUSJBRROR  is  raised  if  FILE  is  not  open. 


5.3.5.10  Determining  the  prcnpt  string 

function  PROMPT  (TERMINAL  :  in  FUZJWPE)  return  STRIN3; 

Purpose: 

This  function  returns  the  current  prenpt  string  for  FILE. 
Parameters: 

TERMINAL  is  an  open  terminal  handle. 

Exceptions: 

USEJEKRQR  is  raised  if  the  attribute  TERMINALjroPE  does 

not  have  the  value  SCROLL. 

STATUS^ ERROR  is  raised  if  FUE  is  not  open. 


5.3.5.11  Determining  interested  characters 

function  INTERCEPTEDJ2HARACTERS  (FIIJE  :  in  FDJBTXPE) 
return  CHAFACTER_LIST;  *“ 

Purpose: 

This  function  returns  the  array  CHAIV£TER_LIST  that  indicates  the 
characters  that  aamot  be  read  by  a  process.  A  value  of  TRUE 
indicates  that  the  character  can  be  read  (otherwise  EALSE) . 

Parameters: 

FILE  is  an  open  terminal  handle. 

Exceptions: 

USE_ERH0R  is  raised  if  the  attribute  FTI£_KIND  does  not  have 

the  value  TERMINAL. 


STATUS  ERROR 


is  raised  if  FILE  is  not  open 


PROPOSED  MUt-STD-CAIS 
31  OCT  1904 


5.3.5.12  Enabling/disabling  function  key  usage 

function  ENABLE  ETJNCTICN_KEYS  (TERMINAL  :  in  FUETCPE; 

ENABLE  s  in  BOOLEAN); 

Purpose: 

This  procedure  establishes  whether  function  key  sequences  are  to  be 
read  as  ASCII  diaracter  sequences  or  as  ranter ed  function  keys  in  a 
terminal  read  operation.  A  value  of  HUE  for  ENABLE  indicates  that 
the  function  keys  should  be  returned  as  a  rurber.  A  value  of  FALSE 
indicates  that  the  function  keys  should  be  returned  as  an  ASCII 
character  sequence. 

Parameters: 

TERMINAL  is  an  open  terminal  handle. 

ENABLE  indicates  how  function  keys  are  to  be  read. 

Exceptions: 

USEJERROR  is  raised  if  the  attribute  FHEJQND  does  not  have 

the  value  TERMINAL. 

SEAXUS_E3ttOR  is  raised  if  FILE  is  not  open. 


5.3.5.13  Determining  function  key  usage 

function  RJNCTICN_KEYS_ENAHL£D ( TERMINAL  :  in  FIIE_TYPE) 
return  BCXXEAN; 

Purpose: 

This  function  returns  TRUE  if  the  function  keys  are  enabled 
(otherwise  FALSE). 

Parameters: 

TERMINAL  is  an  open  terminal  handle. 

Exceptions: 

USEJ2RRDR  is  raised  if  the  attribute  fttjmctnd  does  not 

have  the  value  TERMINAL. 

STATUS  ERROR  is  raised  if  FILE  is  not  open. 
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5.3.S.14  Creating  an  associated  queue 

procedure  ASSOCIATE 

(QUEUE  BASE  t  In  NODE  TOPE; 

QUEUE- KEY  t  in  RaxnCNSBXP  KEY  *-  LATEST  REST; 

auBUEjRBuarai  *  in  fbatxcn  tnc  *-  cdwult  fbjoton; 

FIXE  NOCE  :  in  MOOS  TOR; 

PORT  :  in  LISTTOPE  j-  BVTOJJST; 

ATTRIBUTES  t  in  LIST- TYPE?  —  intantlcnally  not  defaulted 
ACCESS  C&TTBOL  t  in  3*K  STRING  *»  "» 

LEVELx  in  K*MjSTRING  7-  "") 

Purpose: 

This  procedure  creates  an  associated  quaua.  The  queue  node  to  be 
created  is  identified  by  the  dUEUE  BASE/QUEUE  KEf/QUBUEJOaXTICNSHIP 
tried;  the  file  node  with  which  tSs  queue  nc3e  is  to  be  associated, 
is  identified  by  the  open  node  handle  FH2JKXE.  The  type  of  queue 
is  specified  in  FORM  by  the  value  of  the  attribute  OUBUBJRPE.  A 
value  of  COPY  (i.e.  "(QUEUEJKPE  ->  OOPY)")  specifies  that  a  copy 
queue  is  to  be  created.  ~ A  value  of  MIMIC  (i.a.  " (QUEUE  7YPE  ■> 

MIMIC)”)  specifiae  that  a  nrimtr  queue  is  to  be  created.  A 
relationship  ASSOCIATE  is  created  arena  ting  from  the  queue  node  to 
the  file  node  identified  by  the  open  node  handle  FHE_NQDE.  The 
queue  node  that  is  created  inherits  the  ACCESS_raTHOD~of  the  file 
node  with  which  it  is  associated.  A  DIRECT  file  (one  whose 
ACCESS JCTHOD  is  DIRECT)  cannot  be  wrtwrifwl  or  aopied. 

The  ATTRIBUTES  parameter  defines  and  provides  initial  values  for 
attributes  of  the  nods  (for  the  use  of  values  of  type  LISTTOPE,  see 
Section  5.4.  (CAISJUISTjmLITIES).  The  ACCESS JXNTRCL  parameter 
specifies  initial  access  control  information  to  be  established  for 
the  created  node. 

The  IEVQ<  parameter  specifies  the  security  level  at  which  the  file 
node  is  to  be  created. 

Parameters: 

QUEUE_BASE  is  an  open  handle  to  the  node  from  which  the  primary 

relationship  to  the  now  nods  is  to  emanate. 

QUEUE_KEY  is  the  relationship  key  of  the  primary  relationship 

~  to  be  created. 

QUEUEJRHAnCN  is  the  relation  name  of  the  primary  relationship  to 
~  be  created. 

FHE_NDCE  is  an  open  handle  to  the  file  node  with  which 

the  queue  is  to  associated. 

FORM  indicates  fils  characteristics. 

ATTRIBUTES  defines  initial  values  for  attributes  in  the  newly 

created  node. 
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ACCESS  OCNTRX 


defines  the  initial  access  control  information 
associated  with  the  created  node. 


LEVS. 


defines  the  classification  label  for  the  created 
node. 


Exceptional 

MMCJQEOCR  is  raised  if  a  node  already  exists  for  the  node 

identification  given  for  the  queue  node  to  be 
created,  if  this  node  identification  is  syntactically 
illegal,  ACCESSJXNIHJL  parameter  is  unobtainable. 

STATUS_EKCR  is  raised  if  QUEUE_BASE  is  not  an  open  node  handle, 
~  or  if  FILE  is  an  open  file  handle  prior  to  the  call. 

mTEOTJ^IOLATICN  is  raised  if  QUEUE_BASE  was  not  opened  with  an 

intent  establishing  the  right  to  append 
relationships. 


SBCURITC_VIOLATICN  is  raised  if  the  operation  represents  a  violation 
of  mandatory  security  rules.  SBCURTTC_VIGLATICN  is 
raised  only  if  the  conditions  for  other  exceptions 
are  not  present. 

Additional  Interfaces 


procedure  ASSOCIATE  (QUEUE_NAME 

FILE  NODE 
FOSM- 
ATTRIBCTES 

access  asmcL 
LEVEL  ~ 

is 

BASE  i  NCCEJTOPE; 
begin 

OPEN(BASE,  BASE  NAME  (QUEUE  'SMC ) ,  (APPE2C_REXATICNSHIPS ) ; 
ASSCXHA3E (BASE, ~LAST_KE5f (QUEUE  MA»),  IAST  RELATION (QUEUE_NAME ) , 
FH£_MXE,  FORM,  ATTRIBUTES,  ACCESS  CONTROL,  LEVS,); 
CLOSE  (BASE); 
exception 

when  others  ■> 

CLOSE  (BASE); 
end  ASSOCIATE; 


t  in  NA*£_STRING; 
i  in  NCCEJTOFE; 

I  in  LTSTjrePE  i»  EMPTOJLIST; 
t  in  LISTJTOFE;  "** 

i  in  FORM_SIRING 

i  in  FCSM  STRING  "") 


procedure  ASSOCIATE  (QUEUE  BASE  i 

QUEUEJCESf  t 

OUEUE_RELAXICN  t 

FILE  NA«  i 

FORM-  i 

ATTRIBUTES  i 


in  NODE  TOPE; 
in  RELASlCNSHIPJCESf  l« 
LATEST  KEY; 
in  ROATIGN  NAMS 

DEFAULT  RELATION; 
in  NAJCSIRING;  ~ 
in  LIST- TOPE  !■  EMPTO_LIST; 
in  LIST- TOPE; 
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ACCESS  OONIRCL  :  in  FORM  STRING  :- 

LEVO.  “  t  in  FORMJCTRXNS  :«  "")  ' 

is 

FUejaX  t  NOOEJKPE; 
begin  ”  ” 

opdKfxle  tax,  file  me,  (read  attributes)  )  ; 

ASSOCLAIETaUEUE  BASE?  aUBUE  KEf,  QUEUE  RBATZCH, 

FILE  Kie,  FORM,  MTRIBJIES,~JKrESS  OOHRCL,  LEVEL)? 
CLOEE(FILEJXXE); 
exception 

whan  others  -> 

OD6E(FILZ  NOCE); 
end  ASSOCIATE; 

procedure  ASSOCIATE  (QUEUE  NAME  t  in  EMC  STRING; 

FILE  NAME  t  in  »«“sriRING; 

FORM”  :  in  LIST- TXPE  *•  B*TY  LIST; 
ATTRIBUTES  t  in  LIST- TSfPE;  “ 

ACCESS  OCNTROL:  in  “  FORM  SIRING  :- 
LEVEL  “  t  in  FORM_SnakS  *-  "") 
is 

ETLEJKOE  :  NXE_TXPE; 

OUBUEJBASE  :  NCDEJRPE; 
begin 

OPEN  (QUEUE  BASE,  BASE  EMH  (QUEUE JMC),  (APPEM3  RHUOTCNSHIPS) ) ; 
OPEN  (FILE  NODE,  FILEjWB,  (READ~ATTRIBUTES) );  ~ 

assoctaxeTqubue  base,  last  ket (queue  me), 

~  LAST  BELKnON(aUEUE  SAME), 
FILE  NODE,  FORM,  ATTRIBUTES,  AGCTSSJXMIRCL,  LEVEL); 
CLOSE (QUEUEJ3ASE ) ; 

CLOSE  (FILE _NCOE); 
exception 

when  others  *> 

CLOSE (QUEUE  BASE) ; 

CLOSE  (FILE  NODE); 
end  ASSOCIATE; 


5.3.6  tedeege  (MSJ9CRCLLJIEHMINAL 

This  package  provides  the  functionality  of  a  scroll  terminal.  A  scroll 
terminal  consists  of  two  devices:  an  ir^ut  device  (keyboard)  and  an 
output  device  (a  printer  or  display) .  A  scroll  terminal  nay  be  accessed 
either  as  a  single  file  of  mode  INCOT_FIIE  or  as  two  files:  one  of  mode 
INJETLE  (the  keyboard)  and  the  other  of  mods  OUT_FILE  (the  printer  or 
display).  As  keys  are  pressed  an  the  scroll  terminal  keyboard,  the 
transmitted  characters  are  nmde  available  for  reading  by  the 
CAIS  SOCLLjrnwiNAL  package.  As  dmracters  are  written  to  the  scroll 
terminal  file,  they  are  displayed  on  the  output  device. 

Each  of  the  output  devices  far  a  scroll  terminal  has  "positions"  in 
which  printable  ASCII  characters  may  be  graphically  displayed.  The 
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positions  are  arranged  into  horizontal  cows  and  vertical  oolums.  Each 
position  is  identifiable  by  the  combination  of  a  sow  ranter  and  a  oolum 
nutter.  The  active  position  on  the  output  device  of  a  scroll  terminal 
is  the  position  at  which  the  next  operation  will  be  performed.  Hie 
active  position  is  said  to  "advance"  if  (1)  the  row  nutter  of  the  new 
position  is  greater  than  the  row  nutter  of  the  old  position  or  (2)  the 
row  nutter  of  the  new  position  is  the  same  as  the  row  nutter  of  the  old 
position,  but  the  new  position  has  a  greater  oolum  matter. 

A  display  has  a  fixed  nutter  of  rows  and  oolums.  The  rows  and  oolums 
of  a  display  are  identified  by  positive  nutters.  The  rows  are 
incrementally  indexed  starting  with  one  at  the  top  of  the  display.  The 
oolums  are  incrementally  indexed  starting  with  one  at  the  left  side  of 
the  display. 

A  printer  has  a  fixed  nutter  of  columns  and  might  have  a  fixed  nutter  of 
rows.  The  rows  sue  incrementally  indexed  starting  with  cne  after 
opening  the  device  or  performing  the  NEW_P*GE  (Section  5.3.7.19) 
operation.  The  oolums  are  incrementally  indexed  starting  with  one  at 
the  left  side  of  the  printer. 


5. 3.6.1  Types,  subtypes,  constants,  and  exceptions 


subtype  FILE  TYPE  is  CA1S_I0JXNTRX.ETU:_TYPE; 


subtype  ETMCnOI  KEY  DESCRIPTOR  is 

cMsjrojxenrcL.Hicraciy^ 

subtype  TABJNUfERATICN  is  CMS  10  OCNXRCL.TAB  ENUMERATICN; 


USE  ERROR  s 
MXE_EHRCR  s 

snvros  jaacR  t 

LAYOOTJQWOR  : 
DEVICE  ERROR  : 


exception  renames  CMS  I0_EK£PT1CNS.USE_ERR0R; 
exception  renames  CAIS~IO_EXCEPTiaNS .  MXE_ERRCR; 
exception  renames  CAIS_I0_EXCEmCNS.SI3mJS_EIWDR; 
exception  renames  CA15_I0_E?CCEPTICKS .  IAYOUr_ERROR; 
exception  renames  CMS  10  BOSPTICNS.  DEVICE  ERROR; 


FHE_TYPE  is  used  for  file  handles.  ETJNCTICN_KEY_DESC311PTCR  is  used  to 
obtain  information  about  function  keys  read  fircm  a  terminal. 
TABJBKMERKTICN  is  used  to  specify  the  type  of  tab  stop  to  be  set. 
USEJERROR  is  raised  if  an  operation  is  attempted  that  is  not  possible 
far  reasons  that  depend  on  the  characteristics  of  the  external  file. 
MDCE_ERROR  is  raised  by  an  attsnpt  to  read  from  a  file  of  mode  OUT  FILE 
or  write  to  a  file  of  mode  in_FILE.  STA3US_ERR0R  is  raised  iT  the 
handle  an  the  terminal  file  is  not  open.  DEVICE  ERROR  is  raised  if  an 
input  or  output  operation  cannot  be  oarpletsd  Because  of  a  malfunction 
of  the  underlying  system.  LAYOUT  STOR  is  raised  by  an  attsnpt  to  set 
oolum  or  row  nuiters  in  excess  of  specified  maximun  values. 
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5. 3.6. 2  Setting  the  active  poaitlon 

procedure  SBT_P0BIT10B  (1BMXML  (  in  FUBJHSBi 

“  KJSmCM  t  in  FOSmCN  TYPE); 


Purpo— t 

This  procedure  advances  the  active  position  to  the  aped  fled 
EOSmcN  in  the  teniml  file  given  toy  TERMINAL. 

TDMINAL  is  an  open  handle  on  a  teradnal  file, 

posmai  is  the  nee  active  position  in  the  teradnal  file. 


KXEJQ8CR 

srcnusjascR 

IAYOUT_ERHOR 

DEVICE  ERROR 


is  raised  if  a  value  of  the  attribute  TEFMINAL_TYPE 
is  not  9001. 

is  raised  if  TEMOM.  is  of  node  1N_RIB. 

is  raised  if  TEMDKi  is  not  qpan. 

is  raised  if  tits  position  does  not  exist  on  the 
iwi  or  the  position  precedes  the  active 
position. 

is  raised  if  an  input  or  output  operation  cannot  be 
asplebad  because  of  a  malfunction  of  the  underlying 


Additional  Interface! 

procedure  SET_P06mai  (POSTTICK  t  in  POSTTICBI  TYPE) 

is  ~ 

begin 

SET_P06mCM ( CURRENT  OUTPUT,  POSITION); 
end  SET- P06ITICN; 


5. 3.6. 3  Determining  the  active  poaitlon 

function  POSITION  (TERMINAL  t  in  FXZZJKPE) 
return  POSmcN_TYPE ;  “ 

Purpose! 

This  function  returns  the  active  position  of  CTMXNAL. 
Parameters! 

TERMINAL  is  an  opan  handle  an  a  terminal  fila. 


Exceptions! 
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USE__ERROR  is  raised  if  a  value  of  the  attribute  TEFMINALJWre 

is  not  SCRXL. 

MXEJERRCR  is  raised  if  TERMINAL  is  of  mode  INFILE. 

SDOOS_nW0R  is  raised  if  TERMINAL  is  not  open. 

ceviCE_ERRCR  is  raised  if  an  input  or  output  operation  cannot  be 

“  acepletad  because  of  a  malfunction  of  the  underlying 

system. 

Additional  Interface! 

function  POSITION 

return  positicn  type 

ie 

begin 

return  POsmCNfajKOOTjOTPUTh 
end  POSITICN; 


5.3. 6.4  Determining  the  size  of  the  terminal 

fwcticn  SIZE  (THJMDJAL  t  in  PILE  TOPE) 
return  FOSTTICNTOPE; 

Purpoeet 

This  function  returns  the  mazimum  rear  and  maximum  column  of 
TERMINAL.  A  value  of  zero  for  the  row  number  indicates  that  the  row 
number  is  unlimited. 

Parameters! 

TERMINAL  is  an  open  handle  an  a  terminal  file. 

Exceptions! 

USE  OOCR  is  raised  if  a  value  of  the  attribute  TERMINAL_TOPE 

is  not  SCROLL. 

MXE_ERRCR  is  raised  if  TERMINAL  is  of  mode  INJPTLE. 

STASTUS_ERRCR  is  raised  if  TEEKINAL  is  not  open. 

EEVICE_EKRDR  is  raised  if  an  input  or  output  operation  cannot  be 

(xnpleted  because  of  a  malfunction  of  the  underlying 
system. 

Additional  Interface: 

function  SIZE 

return  POSITION  TOPE 
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return  SIZE  (CUHRENr_Otfnvr) ; 
end  SIS;  ~ 


5. 3.6. 5  Setting  a  tab  stop 

procedure  SET  TAB  (TBMXNAL  i  in  P HE  TYPE; 

KDS  »  in  TKBjbUMDtMTION  *-  BDRiaOOTAL) ; 

Purpose: 

This  procedure  establishes  a  horizontal/ vertical  tab  stop  at  the 
oolimn/row  of  the  active  position. 

Parameters: 

TBMINAL  is  an  open  handle  on  a  terminal  file. 

Exceptions: 

USE_BOCR  is  raised  if  a  value  of  the  attribute  TS5SMINALTYPE 

“  is  not  9CSXL  or  the  amber  of  nows  for  the  terminal 

is  unlimited. 

MQCE_ERHCR  is  raised  if  TBMXML  is  of  mode  IN  FILE. 

SCKrus_ERROR  is  raised  if  TBMXNAL  is  not  open. 

EEVICE_ERHCR  is  raised  if  an  input  or  output  operation  aannot  be 

ampietad  because  of  a  malfunction  of  tbs  wderlying 

systeau 

Additional  Interface: 

procedure  SETJEAB  (KUO  i  in  TAB_HMCRKTXCN  ;•  HORIZCNEHL) 

is  ” 

begin 

SETjaB(aUBBEOT_INPOT,  KIND); 
end  SET- CAB; 


5. 3. 6.6  Clearing  a  tab  stop 

procedure  CZAR  TAB  (TERMINAL  :  in  FILE  TYPE; 

KHD  i  in  TAbJbKJMHATIGN  *■  fORIZCHTAL); 

Purpose; 

This  procedure  removes  a  horizontal/ vertical  tab  stop  fra  the 
oolum/row  of  the  active  position. 

Parameters: 

TERMINAL  is  an  open  handle  on  a  terminal  file. 


Exceptions; 
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usb  aacR 


MXE  BOOR 


is  raised  if  a  value  of  the  attribute  TBMINAL_TYFE 
ie  not  9CHXI*  or  theca  ia  no  tab  atop  of  the 
decimated  type  at  the  active  poeiticn. 

is  raised  if  TERMINAL  is  of  node  IN  FILE. 


SEAlUBJOtROR  is  raised  if  TBMINAL  is  not  open. 

OSVICEJBSBR  is  raised  if  an  input  or  output  operation  cannot  be 

completed  because  of  a  malfunction  of  the  underlying 
systan. 


Additional  Interfaces 


procedure  CLEAR  TAB  (KIND  s  in  TAB  ENUMERATION  :«  HDRI2CNTAL) 

is 

begin 

OEARJEAB ( CURRQJr J3UTPUT ,  KUO); 
end  CLmMCSAB; 


5.3. 6.7  Advancing  to  the  next  tab  position 

procedure  TAB  (TBMINAL  t  in  F HE  TYPE? 

KIND  i  in  T3VB_QHCRATIGN  t-  HORIZONTAL? 
COUNT  t  in  POSmVB  :■  1); 


Purposes 

This  procedure  advances  the  active  position  COUNT  tab  stops. 
Harinxital  advancement  causes  a  change  in  only  aolum  nunfcer  of  the 
active  position.  Vertical  advancement  causes  a  change  in  only  the 
row  nurber  of  the  active  position. 


TBMINAL 


is  an  open  handle  on  a  terminal  file. 


COUNT 


is  a  positive  integer  indicating  the  mxnber  of  tab 
stops  the  active  position  ie  to  advance. 


Exceptions t 
UBE  BtRQR 


is  raised  if  a  value  of  the  attribute  TBMINAL_TYPE 
ie  not  SCROLL. 


MXEJERRCR 
STMISERRCR 
DEVICE  ERROR 


is  raised  if  TERMINAL  is  of  mode  IN_ETLE. 

is  raised  if  TBMINAL  ia  not  open. 

is  raised  if  an  input  or  output  operation  cannot  be 
oonpleted  because  of  a  malfunction  of  the  underlying 
system. 


Additional  Intarface: 
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procedure  XKB  (KQD  t  in  TAB  BUCRKTXGN  :■  BBTSOKEMi} 
OCUIT  t  in  POSITIVE  i-  1) 

is 

*»g>n 

TM(OJKREOT_ai7nVr,  KHD|  OCUfT); 
end  TAB; 


5. 3.6.8  Sounding  a  terminal  bell 

procedure  BOX  { TERMINAL  t  in  FZZJEjnPB); 

Purpose: 

This  procedure  aicpiala  the  bell  (beeper)  on  the  terminal. 


TERMINAL 


is  an  open  handle  an  a  terminal  die. 


Exceptions: 

USE_ERR» 

MOOE_ERROR 

SEMUSERHCR 

DEVICE  E3WCR 


is  raised  if  a  value  of  the  attribute  TBMZNALJHPE 
is  not  SCRCUi. 

is  raised  if  TEMXNAL  is  of  node  IN_FHE. 

is  raised  if  TERMINAL  is  not  open. 

is  raised  if  an  input  or  output  operation  aannot  be 
ccepleted  because  of  a  malfunction  of  the  underlying 

system. 


Additional  Interface: 


procedure  BEIX 

is 

begin 

box  (ajRRjon’jxmvr ) ; 
end  BOX; 


5. 3.6.9  Writing  to  the  terminal 

procedure  FVT  (TB9HNAL  :  in  FILE  TYPE; 

ITEM  :  in  CHARACTER); 

Purpose: 

This  procedure  voltes  a  single  character  to  the  output  device  and 
advances  the  active  position  by  one  position. 

Parameter: 

TQMDUAL  is  an  open  handle  on  a  terminal  file. 

ITEM  is  the  character  to  be  written. 


PROPOSED  MIIr-STD-CAIS 
31  OCT  1984 


Exceptions: 

USE_EKROR  is  raised  if  a  value  of  the  attribute  TESMINALjrePE 

is  not  SCRCU,. 

MXEJERRDR  is  raised  if  TBWINAL  is  of  nods  m_FXL£. 

STATOSJERHDR  is  raised  if  TERMINAL  is  not  open. 

GEVICE_ERR0R  is  raised  if  an  input  or  output  operation  cannot  be 

canpleted  because  of  a  malfunction  of  the  underlying 
system. 

Additional  Interface: 

procedure  PUT  (ITEM  :  in  CHARACTER) 

is 

begin 

POT(OJRREOT_OOTPOT,  ITEM); 
end  POT? 

procedure  PVT  (TBMXNAL  s  in  FXUJHPB; 

ITEM  :  in  STRING) 

is 

begin 

far  INDEX  in  ITSI1  FIRST  ..  ITEM' LAST  loop 
POT(TERMINAL,  ITTM(  INDEX)  ); 
end  loop? 
end  EOT; 

procedure  POT  (ITEM  s  in  STRING) 

is 

begin 

POT(aJRREOT_COTIOT.  ITEM); 
end  POT; 

Notes: 

After  writing  the  character  in  the  rightmost  position  of  a  row,  the 
active  position  is  the  first  position  of  the  next  row. 


5.3.6.10  Setting  the  ECHO  on  a  terminal 

procedure  SET  ECHO  (TERMINAL  :  in  FILE  TYPE; 

TO  :  in  BOOLEAN  :-  TRUE); 

Purpose: 

This  procedure  establishes  whether  characters  entered  at  the 
terminal  keyboard  are  echoed  to  its  associated  output  device.  When 
TO  is  given  as  TRUE,  each  character  entered  at  the  keyboard  is 
echoed  to  the  output  device.  When  TO  is  given  as  FALSE,  characters 
ontered  at  the  keyboard  are  not  echoed  to  its  associated  output 
device. 
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Parameters: 

TERMINAL  is  an  open  handle  on  a  terminal  file. 

TO  indicates  the  new  value  at  ECHO. 

Exceptional 

USE_BOCR  is  raised  if  a  value  of  the  attribute  TBMINALJHPE 

is  net  SCROLL. 

MODE  ERROR  is  raised  if  TSMXNAL  is  of  mode  OCT  FLUE  or 

APPBD_FILE. 

SEATOS_ERROR  is  raised  if  TERMINAL  is  not  open. 

DEVTCE_ERRCR  is  raised  if  an  input  or  output  operation  cannot  be 

ocnpleted  because  of  a  malfunction  of  the  underlying 

system. 

Additional  Interface: 

procedure  SET  WED  (TO  t  in  BOOLEAN  :-  TRUE) 

is  ~ 

begin 

SET_BCH3(CURRQfr  INPUT); 
end  SET  ECHO; 


5.3.6.11  Determining  the  ECHO  on  a  terminal 

function  ECHO  (TEWGNAL  :  in  FUEJTYFE)  return  BOOLEAN; 

Purpose: 

This  function  returns  whether  echo  is  enabled  (TRUE)  or  disabled 

(FALSE). 

Parameters: 

TERMINAL  is  an  epan  handle  cn  a  terminal  file. 

Exceptions: 

USE  ERROR  is  raised  if  a  value  of  the  attribute  TERMINAL  TYPE 

is  not  SCROLL. 

MXE  ERROR  is  raised  if  TEEMINAL  is  of  mods  OUT_FH£  or 

APPEND_PILE. 

STATUSJERROR  is  raised  if  TERMINAL  is  not  open. 

CEVICE_ERROR  is  raised  if  an  input  or  output  operation  cannot  be 
acnpleted  because  of  a  malfunction  of  the  underlying 
system. 


Additional  Interface: 
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function  BCH3  return  BQCX£W 

is 

begin 

return  Eac(CURRENT_INPOT)  ? 
end  ECHO; 


5. 3.6. 12  Determining  the  nuitoer  of  function  keys 

function  FINOTOTKEYS ( TERMINAL  j  in  FUETYPE) 
return  NATURAL; 

Purposes 

This  function  returns  the  imxirnun  function  key  identifier  that  can 
be  returned  by  a  GET  operation  in  the  terminal  file  given  by 
^EEHQAL* 

Parameters: 

TERMINAL  is  an  open  handle  on  a  terminal  file. 

Exceptions! 

USEJERROR  is  raised  if  a  value  of  the  attribute  TERMINAL_TXPE 

is  not  SCRXXi. 

MXE_ERROR  is  raised  if  TERMINAL  is  of  mode  CUT  FILE  or 

“  APPEND_FHE. 

SEA1US_E3®CR  is  raised  if  TERMINAL  is  not  open. 

DEVICE_HRHCR  is  raised  if  an  input  or  output  operation  cannot  be 

ccnpleted  because  of  a  malfunction  of  the  underlying 
system. 

Additional  Interfaces 

function  EUNCTICNJCEYS  return  NATURAL 

is 

begin 

return  IU9CTICNKEYS  ( CURRDrrjNPVT ) ; 
end  HJNCTICN  KEYS:  ~  ” 
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5.3.6.13  Reading  a  character  frcm  a  terminal 

(TERMINAL  :  in  ETtEJTYPE; 

ITEM  T  out  CHARACTER; 

KEYS  :  in  out  ETJMCnCW_KEY_DESCRIPlXJR)  ; 

Purpose: 

This  procedure  reads  either  a  single  character  into  ITEM  or  reads 
a  single  function  key  into  KEYS. 


Parameters: 

TERMINAL 

ITEM 

KEYS 

Exceptions: 

USE_ERHOR 

MXE  ERROR 
SEATUS_EKRCR 
DEVICE  ERROR 


is  an  open  handle  on  a  terminal  file, 
is  the  character  that  was  read, 
describes  the  function  key  that  was  read. 

is  raised  if  a  value  of  the  attribute  TE»GNAL_TYPE 
is  not  SCROLL. 

is  raised  if  TERMINAL  is  of  mode  LNJsTLE. 

is  raised  if  TERMINAL  is  not  open. 

is  raised  if  an  input  or  output  operation  cannot  be 
ocnpleted  because  of  a  malfunction  of  the  underlying 
system. 


Additional  Interface: 

(ITEM  :  out  CHARACTER; 

KEYS  :  in  out  PUNCTICNJCEY  DESCRIPTOR) 
is 

begin 

GEr(OJRREOT_OOTPUT,  ITEM,  KEYS); 
end  GET; 


5.3.6.14  Reading  all  available  characters  from  a  terminal 

procedure  GET(THWINAL  :  in-  FH£_TYPE; 

ITEM  :  out  STRING; 

LAST  :  out  NATURAL; 

KEYS  :  in  out  FUNCTION  KEY  DESCRIPTOR); 


Purpose: 

This  procedure  successively  reads  characters  and  function  keys  into 
ITEM  and  KEYS  until  either  ail  positions  of  ITEM  are  filled  or  there 
are  no  more  characters  buffered  for  the  terminal.  Upon  oonpletion, 
LAST  contains  the  index  of  the  last  position  in  ITEM  to  contain  a 


144 


fc 


3-172 


PROPOSED  MIL-SID-CAIS 
31  OCT  1984 


character  that  has  been  read.  In  addition,  the  function  keys  that 
were  read  are  entered  into  KEYS. 


Parameters: 

TERMINAL 

ITEM 

LAST 

KEYS 

Exceptions: 
USE  ERROR 


is  an  open  handle  on  a  terminal  file, 
is  the  characters  that  were  read, 
is  the  position  of  the  last  character  read  in  ITEM, 
describes  the  function  keys  that  were  read. 

is  raised  if  a  value  of  the  attribute  TERMINAL_TYPE 
is  not  SCROLL. 


MXE_ERHOR  is  raised  if  TERMINAL  is  of  node  IN_FILE. 

STAIUS_ERROR  is  raised  if  TERMINAL  is  not  open. 

EEVICE_E3®OR  is  raised  if  an  input  or  output  operation  cannot  be 

completed  because  of  a  malfunction  of  the  underlying 
system. 

Additional  Interface: 


procedure  GET  (ITEM 
LAST 
KEYS 

is 


:  out  STREWS? 

t  out  NATURAL; 

:  in  out  EUKdTCN  KEY  DESCRIPTOR) 


begin 

<3ET(CURRE»r_INPOT,  ITEM,  LAST,  KEYS); 
end  GET; 


Notes: 

If  there  are  no  elements  available  for  reading  from  the  terminal, 
then  LAST  has  a  value  one  less  than  ITEM' FIRST  and 
FUNCTICN_KEY_OCWr (KEYS )  is  equal  to  zero. 


5.3.6.15  Determining  the  ruriber  of  function  keys  that  were  read 

function  EUNCTICNJ®f JXLNT  (KEYS  :  in  FUNCTION JCEYJXSCRIPTOR ) 
return  NATURAL; 

Purpose: 

This  function  returns  the  neither  of  function  keys  described  in  KEYS 
Parameters: 

KEYS  is  the  function  key  descriptor  being  queried. 

Exceptions:  none 


■■•u-p, 
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5.3.6.16  Dfradning  function  1 cay  usage 

procadurs  FUNCTION  KEY(KEYS  *  in 

FUNCTION  KEY  DESCRIPTOR; 

ncex  s  in  POSITIVE; 

Res’  namna  *  out  positive; 

postticn  «  out  natural); 


Purpose; 

This  procedure  returns  the  identification  nustosr  of  a  function  key 
and  the  position  in  the  string  (read  at  the  sane  tine  as  the 
function  keys)  of  the  character  following  the  function  key. 


Parameters* 

KEYS 

INDEX 


of  faction  keys. 


is  the  function  key 


KEY  xuaiTiPiigt  is  the  identification 


to  be  queried, 
of  a  function  key. 


posmcN 


is  the  position  of  the 
faction  key. 


Exceptions* 

OCNSTRAIOTJERRCR  is  raised  if  BBEX 
FUNCTION  KEY  COUNT  (KEYS). 


read  after  the 


greater  than 


5.3.6.17  Determining  the  name  of  a  faction  key 

procedure  FUNCTICN_KEY_NN«  (TERMINAL  i  in  PHETYR; 

KEY  XDOfTXFIER  *  in  POSITIVE; 

KE30JAME  t  out  STRING; 

IAST  *  out  POSITIVE); 

Purpose* 

This  faction  returns  (in  KEY_NMC)  ths  name  of  the  function  key 
sequence  designated  by  KEY  IDENTIFIER,  it  also  returns  the  index,  of 
the  last  character  of  the  Tiaction  key  name  in  INDEX. 

Parameters* 

TERMINAL  is  an  open  handle  on  a  terminal  file. 

KEYJCCQfTIFIER  is  the  identification  rusher  of  a  function  key  far 
”  the  terminal  associated  with  FXXZ. 


KEY  NAME 


Exceptions* 


is  the  name  of  the  key  designated  by  KEY_ZDENTIFZER. 

is  the  position  in  KEY_NNfS  of  the  last  character  of 
the  function  key  nama.  — 
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US  BtiOR  is  raised  if  a  value  of  the  attribute  TBMCNAL  TYPE 

is  not  SCROLL. 

MXEJ30CR  is  raised  if  TERMINAL  is  of  nods  IN_FTL£. 

SIMUS_ERROR  is  raised  if  TERMINAL  is  not  open. 

DEVTCEJ3®0R  is  raised  if  an  input  or  output  operation  cannot  be 

completed  because  of  a  malfunction  of  the  underlying 
system. 

CONSTRAINT  ERROR  is  raised  if  the  value  of  KEY  IDENTIFIER  is  greater 
than  FUNCTICNKEYS  (TERMINAL). 

Additional  Interface: 

procedure  FUNCTION  KEY  NAS 

(KEY  IDENTIFIER  :  in  POSITIVE: 

KEY- NAS  :  out  STRING; 

LAST  :  out  POSITIVE) 

is 

begin 

FUNCTION  KEY  NAS(GURRENT  INPUT, 

KEY  IDENTIFIER,  KEYNAME,  IAOT); 

end  FUNCTION  KEY  NAS;  ~ 


5.3.6.18  Advancing  the  active  position  to  the  next  line 

procedure  NEW_LINE  (TSMINAL  :  in  FILE  TYPE? 

COUNT:  in  POSITIVE  :«  1); 

Purpose: 

This  procedure  advanoee  the  active  poaition  to  column  one,  COUNT  lines 
after  the  active  position. 

Parameters* 

TERMINAL  is  an  open  handle  an  a  terminal  file. 

GOUtT  is  the  timber  of  lines  to  advance. 

Exceptions: 

USEJSfcROR  is  raised  if  a  value  of  the  attribute  IERMINAL_TYPE 

is  not  SCRCLL. 

MQCEJERROR  is  raised  if  TERMINAL  is  of  mode  IN_FnJE. 

STATUS_ERROR  is  raised  if  TERMINAL  is  not  open. 

is  raised  if  an  input  or  output  operation  cannot  be 
completed  because  of  a  malfunction  of  the  underlying 


DEVICE  ERROR 
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Additional  Interface: 

procedure  tEW  LINE  (OCUfTt  in  POSITIVE  t-  1) 

in 

begin 

t0 f  LINE  (CURRENT  OUTPUT,  CEWT)? 
end  NEW* LINE; 


5.3.6.19  Advancing  the  active  poeition  to  the  next  page 
procedure  NEW_PAGE  (TERMINAL  t  in  FIUE_TYPE); 

Purposes 

This  procedure  advances  the  active  poeition  to  the  first  aolunn  of  the 
first  line  of  a  new  page. 


Parameters! 

TB9GNAL 


USE  ERROR 


is  an 


handle  on  a  termtnal  file. 


is  raised  if  a  value  of  the  attribute  TSMINALTCPE 
is  not  SCROLL. 


HXE  ERROR 


is  raised  if  TERMINAL  is  of  node  IN  FILE. 


STA£HB_ERRCR  is  raised  if  TTWGNAL  is  not  open. 

DEVICE_nW0R  is  raised  if  an  input  or  output  operation  cannot  be 

completed  because  of  a  malfunction  of  the  underlying 

system. 


Additional  Inter&oas 

procedure  EBf_PAGE 

is 

begin 

NDf_PAGE(CURREOT  OUTPUT); 
end  NEW  PAGE; 
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5.3.7  Package  CAI S_PAGE_TERMINAL 

this  package  provides  the  functionality  of  a  page  terminal.  A  page 
terminal  consists  of  two  devices:  an  input  device  (keyboard)  and  an 
outfit  device  (display) .  A  page  terminal  may  be  accessed  either  as  a 
single  file  of  mode  INCUT  FILE  or  as  two  files:  one  of  mode  IN  FILE 
(the  keyboard)  and  the  other  of  mode  CUTJFTU  (the  printer  or  display). 
As  keys  are  pressed  on  the  page  terminal  keyboard,  the  tranmnitted 
characters  are  made  available  for  reading  by  the  CMS  PAGE_TESKOiAL 
package.  As  characters  are  written  to  the  page  terminal  fTle,  they  are 
displayed  on  the  output  device. 

the  display  for  a  page  terminal,  has  positions  in  which  printable  ASCII 
characters  may  be  graphically  displayed.  the  positions  are  arranged 
into  horizontal  rows  and  vertical  ooloms.  Each  position  is 
identifiable  by  the  ccnfainaticn  of  a  row  mother  and  a  aolmn  mother, 
the  active  position  an  the  display  of  a  page  terminal  is  the  position  at 
%4iich  the  next  operation  will  be  performed,  the  active  position  is  said 
to  advance  if  (1)  the  row  mother  of  the  mew  position  is  greater  than  the 
rw  mother  of  the  old  position  cr  (2)  the  row  mother  of  the  new  position 
is  the  seme  as  the  row  mother  of  the  old  position,  but  the  new  position 
has  a  greater  aolian  nether. 

A  display  has  a  fixed  mother  of  r owe  and  ooltaons.  The  rows  and  colucms 
of  a  display  are  identified  by  positive  mothers.  the  rows  are 
incrementally  indexed  starting  with  one  at  the  top  of  the  display,  the 
oaluens  are  incrementally  indexed  starting  with  one  at  the  left  side  of 
the  display. 


5. 3. 7.1  Types,  subtypes,  constants,  and  exceptions 

subtype  FHE_TYPE  is  CAIS_IOjXNIRCL .  FIUE_T¥PE  ; 

subtype  FUNCnCNKEJf  CE3CRIP1UR  is 

avis jtojxntrcl .  H*mc»j<EyjaEsau^ 

subtype  PCSmCNJWFE  is  GAIS JK) JXNTRCL .  P06ITICN_TYPE  ; 

subtype  TABJWttBRATXCN  is  CAIS_IO_CCNnCL .  TAB_B*M«RATICN; 

type  SnjBCT  ENUMERATION  is 

(FROM  KfftVE  POSmCNTO  OD, 

FR0MJ3TART  TO  ACTIVE  POSITION, 

Aix_K)srriaNsT; 

type  GRAPHIC  BBflDmCN  ENUFERATICN  is 
(PRDMOT  RENDITION,”' 

BOLD,  ~ 

FAINT, 

UNDERSCORE, 

SLOW  BLOK, 

RAPID  BLOC, 

REVBSE  IMNX) ; 

type  GRAFHXC_RQDrnCN_ARRA2f  is  array  (GRAPHIC  RENDITION  ENUMERATION) 
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of  B00UN9; 

EEFNJUT  BSOXmCM  t  constant  GRAPHIC  fODmON  ARRAY 
*-  TtaXMUVJODITICN  ->  TRUE,  osiers  ->  FStSE); 

USE  SWCR  t  exception 
MXB  ERROR  s  exception 
STATUS  2RH0R  t  •XCSptlon 
LAYOUT_ERRDR  i  exception 
DEVICE jERRCR  :  exception 

ETLE_TYPE  is  used  for  file  handles.  PUNCnay^JDBSCRIPTOR  is  used  to 
obtain  information  about  function  keys  tend  ~  from  a  terminal. 
PQSITICNTOTE  indicates  a  position  on  a  terminal.  TAB  DXMSRAZXCN  is 
used  to  pacify  the  type  of  tab  stop  to  be  set.  SEU9CT_BuflRNrXCN  is 
used  in  ERASE  IN  DISPLAY  and  ERASE  IN  LIKE  to  determine  the  portion  of 
the  display  or  line  to  be  erased.-  GRAPHIC  REN)lTIGNJSMCRNriGM» 
GRAPHIC  SH©mCN_ARRAY ,  and  DEFAULT  GRAfflIC  iStolTttN  are  ueed  to 
determine  display  characteristics  of  printable  3iaractars.  U5E_ERRQR  is 
raised  if  an  operation  is  attempted  that  is  not  possible  for  reasons 
that  depend  on  the  characteristics  of  the  external  Ole.  MDDEJERROR  is 
raised  by  an  attmpt  to  read  from  a  file  of  mode  aur_FTUB  or  write  to  a 
file  of  mode  HIJFTIE.  STA3US_ERR0R  is  raised  if  the  terminal  is  not 
open.  DEVICE  Irror  is  raised  if  an  input  or  output  operation  cannot  be 
acnpleted  because  of  a  malfunction  of  the  underlying  system. 
IA3TOOT_ERR0R  is  raised  by  an  attenpt  to  set  aoium  or  row  timbers  in 
excess  of  specified  rrexiimm  values. 


5. 3. 7. 2  Setting  the  active  position 

procedure  SET_P06rriCN  (TERMINAL  i  in  FILE  TYPE; 

POSTTICN  t  in  POSmCNJTYPE); 

Purpose! 

This  procedure  moves  the  active  position  to  the  specified  POSITION 
an  the  display  of  the  terminal. 

Parameters! 

TERMINAL  is  an  open  handle  on  a  terminal  file. 

POSITION  is  the  new  active  position  for  the  terminal. 


Exceptions! 

USE  ERROR  is  raissd  if  a  value  of  the  attribute  TERMINAL  TYPE 

is  not  PAGE.  “ 

MXE_ERROR  is  raised  if  TERMINAL  is  of  mode  IN_FHJS. 

STATUS_ERROR  is  raised  if  TERMINAL  is  not  open. 

LAYOUT_BWOR  is  raised  if  the  position  does  not  exist  on  the 
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.USE  ERROR; 
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.LAYOUT  ] ERROR; 
.  DEVICE- ERROR; 
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terminal  or  the  position  precedes  the  active 
position. 

EEVICE_EHROR  is  raised  if  an  input  or  output  operation  cannot  be 
completed  because  of  a  malfunction  of  the  underlying 

system. 

additional  Interfaces 

procedure  SETP06ITICN  (POSITION  :  in  POSrnONJTYPE) 

is 

begin 

SET  POSITION  (CURRENT  OUTPUT,  POSITION); 
end  SET  1 POSITION; 


5. 3. 7. 3  Determining  the  active  position 
function  POSITION  (TBWHBVL  t  in  FHEJKPE) 
return  POSITlON_TVPE  ; 

Purpose! 

This  function  returns  the  active  position  of  TEEMINAL. 

Panmeters: 

TCFMXNAL  is  an  open  handle  on  a  terminal  file. 

Exceptions: 

USE_QOOR  is  raised  if  a  value  of  the  attribute  TERMDBVLjnPE 

is  not  PAGE. 

MXE_ERROR  is  raised  if  TQMDAL  is  of  node  1N_FILE. 

STATUS_ERHCR  is  raised  if  THtOWL  is  not  open. 

DEVICEJERROR  is  raised  if  an  Lgput  or  output  operation  cannot  be 
ocspleted  becauee  of  a  malfunction  of  the  underlying 

system. 

Additional  Interface: 

function  POSITION  return  POSITION  TYPE 

is 

begin 

return  P06ITICN(CURFB7r  OUTPUT) 
end  POSITION; 
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5. 3. 7.4  Determining  the  size  of  the  terminal 

fwcticn  SIZE  (TERMINAL  t  in  FHE_TYPE) 
return  POSmCNTWE; 

Purposet 

This  function  returns  the  naximun  row  and  nwrimin  oolvxm  of  the 
terminal. 

Parameters: 

TERMINAL  is  an  open  handle  on  a  terminal  file. 

Exceptions: 

USE_ERROR  is  raised  if  a  value  of  the  attribute  TERMlNALjnPE 

is  not  PAGE. 

MCCE_ERSOR  is  raised  if  TERMINAL  is  of  mode  IN_FIIE. 

SEATUSJERROR  is  raised  if  TOMINAL  is  not  open. 

DKVICEJQWCR  is  raised  if  an  input  or  output  operation  aamot  be 
oonpleted  because  of  a  malfunction  of  the  underlying 
system. 


Additional  Interface: 

function  SIZE 

return  POSITICNTCTE 

is 

begin  _ 

return  SIZE(CURRQfT  OUTPUT) ; 
end  SIZE; 


5. 3. 7. 5  Setting  a  tab  stop 

procedure  SETJEAB  (TERMINAL  :  in  FILE  TIPS; 

KIND  :  in  TAB_BHU«WriGN  :-  HDRIZONEAL); 

Purpoee: 

This  procedure  establishes  a  horizontal/ vertical  tab  stop  at  the 
oolumn/rov  of  the  active  position. 

Parameters: 

TERMINAL  is  an  opsn  handle  on  a  terminal  file. 

Exceptions: 

USEJERROR  is  raised  if  a  value  of  the  attribute  TCRMINALjnrFE 

is  not  PAGE. 


MXJE  DOCK 


is  raised  if  TERMINAL  is  of  mode  IN  FILE 


PROPOSED  MIL-SID-CAIS 
31  OCT  1984 


STNUS_ERHOR  is  raised  if  TQWINAL  is  not  open. 

CEVICE_E3WDR  is  raised  if  an  input  or  output  operation  cannot  be 
completed  because  of  a  malfunction  of  the  underlying 
systmn. 

Additional  Interfaces 

procedure  SET  TAB  (KIND  :  in  T&BjaWEWITGN 

s-  HORIZONTAL) 

is 

begin 

SET_TAB(CURRENT_INIVr,  KIND); 
end  SET  TAB; 


5. 3. 7. 6  Clearing  a  tab  stop 

procedure  CLEARJTAB  (TERMINAL  t  in  FILE  TYPE; 

KIND  s  in  TAB_a«<ERATICN  :■  HORIZONTAL) ; 

Purposes 

This  procedure  removes  a  horizontal /vertical  tab  stop  from  the 
aolimn/row  of  the  active  position. 

Parameters: 

TERMINAL  is  an  open  handle  on  a  terminal  file. 

Exceptions: 

USE_ERROR  is  raised  if  a  value  of  the  attribute  TERMMAL_TYPE 

is  not  PAGE  or  there  is  no  tab  stop  of  the  designated 
type  at  the  active  position. 

MXE_ERRDR  is  raised  if  TBMINAL  is  of  mode  IN_FHE. 

STATOS_ERRDR  is  raised  if  TERMINAL  is  not  open. 

EEVICE_ERRCR  is  raised  if  an  input  or  output  operation  cannot  be 
aonpleted  because  of  a  malfunction  of  the  ixsderlying 
system. 

Additional  Interfaces 

procedure  CLEAR  TAB  (KIND  :  in  TAB  ENUMERATION  :»  HORIZONTAL) 

is 

begin 

CLEAR  TAB  (CURRENT  OUTPUT,  KIND); 
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5.3. 7. 7  Advancing  to  the  next  tab  position 

procedure  TAB  (TOMHOVL  :  in  FILE  T5OT? 

KUO  :  in  TAB  BKMSWnai  i-  HORIZONTAL; 

COUNT  t  in  POSTnVE  I-  1)} 

Purpose: 

This  procedure  advances  the  active  position  COUNT  tab  stops. 
Horizontal  advancement  causes  a  change  in  only  aolim  nunfeer  af  the 
active  position.  Vertical  advaneeeient  causes  a  dhange  in  only  ths 
row  nunber  of  the  active  position. 

Parameters: 

TERMINAL  is  an  open  handle  on  a  terminal  file. 

OOUNT  is  a  positive  integer  indicating  the  nunber  of  tab 

stops  the  active  position  is  to  advance. 

Exceptions: 

USEJERROR  is  raised  if  a  value  of  the  attribute  TEIMINALJHPE 

is  not  PAGE. 

MOCEJERROR  is  raised  if  TDtONAL  is  of  node  m_FIL£. 

STAOTS_ERROR  is  raised  if  TBMZNAL  is  not  open. 

EEVICE_ERROR  is  raised  if  an  input  or  output  operation  cannot  be 
acmpieted  because  of  a  malfunction  of  dm  underlying 
system. 

Additional  Interface: 

procedure  TAB  (KIND  :  in  TABjaWERATICN  :-  HORIZONTAL; 

COUNT  :  in  POSITIVE  :■  1 

is 

begin 

TAB(ajRRENT_aOTPUT,  KIND,  COUNT); 
end  TAB 


5. 3. 7.8  Sounding  a  terminal  bell 

procedure  BELL  (TERMINAL  :  in  FILE_T¥PE); 

Purpose: 

This  procedure  signals  ths  bell  (beeper)  an  the  terminal. 

Parameters: 

TERMINAL  is  an  open  handle  on  a  terminal  file. 

Exceptions: 

USEJERROR  is  raised  if  a  value  of  the  attribute  TERKINAL_TXPE 

~  is  not  PAGE. 
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MDCEJBWCR  is  raised  if  TERMINAL  is  of  node  IN_FTLE. 

SEMDS_ERROR  is  raised  if  mMINAL  is  not  open. 

DEVICE JSRRQR  is  raised  if  an  input  or  output  operation  cannot  be 

aoqpleted  because  of  a  malfunction  of  the  underlying 
systaa. 

Additional  Interface! 
procedure  BELL 

is 

begin 

sexL(cuRRarr  output); 

end  BEIL; 


S.3.7.9  writing  to  the  terminal 

procedure  POT  (TERMINAL  >  in  out  PIUMKPE; 

rm  i  in  CHARACTER) ; 

Purpoeei 

This  procedure  writes  a  single  diaracter  to  the  output  device  and 
advances  the  active  position  by  one  position. 

Parameter! 

TERMINAL  is  an  open  handle  on  a  terminal  file. 

ITB4  is  the  character  to  be  written. 

Exemptions! 

USE  ERROR  is  raised  if  a  value  of  the  attribute  TERMINAL  TYPE 

is  not  PAGE.  ” 

M3EEJSRCR  is  raised  if  TERMINAL  is  of  mode  INFUJE. 

3TWTJ5_ERR0R  is  raised  if  TBMCNAL  is  not  open. 

CEVIGE_SBOR  is  raised  if  an  input  or  output  operation  cannot  be 
acepleted  bemuse  of  a  malfunction  of  the  underlying 
system. 

Additional  Interface! 

procedure  POT  (OTM  i  in  CHARAdBt) 

is 

begin 

POT(GURRBir  OUTPUT,  ITEM); 
end  POT; 

procedure  MIT  (TERMINAL  i  in  FILE  TYPE; 

item  i  in  snuRs) 
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for  INDEX  in  nsTFZNST  ..  ITBJ'LAST  loop 
POT(TEWHNAL,  nB4(IMXX)); 
end  loop; 
end  PUT? 

procedure  PUT  (ITEM  s  in  STRING) 

is 

begin 

ror(cupRQir  output,  item); 

end  PUT; 

Notes: 

After  writing  the  character  in  the  rightmost  position  of  a  row,  the 
active  position  is  the  first  position  of  the  next  row. 


5.3.7.10  Setting  the  ECHO  on  a  terminal 

procedure  SET_BCHO  (TERMINAL  :  in  FII£  TYPE; 

TO  *  in  BDtlfflH  :-  TRUE); 


Purpose: 

This  procedure  establishes  whether  characters  entered  at  the 
terminal  keyboard  are  echoed  to  its  associated  output  device.  When 
TO  is  given  as  TRUE,  each  character  entered  at  the  keyboard  is 
echoed  to  the  output  device.  When  TO  is  given  as  FALSE,  characters 
entered  at  the  keyboard  are  not  echoed  to  its  associated  output 
device. 

Parameters: 

TERMINAL  is  an  open  handle  cn  a  terminal  file. 

TO  indicates  the  new  value  of  ECHO. 


Exceptions: 

USE_ERROR  is  raised  if  a  value  of  the  attribute 

TERMINALjraE 

is  not  PAGE. 


M3CE_ERRDR 
or  ” 

STATUSJERRCR 

DEVICE_ERRDR 

be 

underlying 


is  raised  if  TERMINAL  is  of  mode  OUT_FHJE 
APPa©_FHE. 

is  raised  if  TERMINAL  is  not  open, 
is  raised  if  an  input  or  output  operation  cannot 
ocnpleted  because  of  a  malfunction  of  the 
system. 


Additional  Interface: 
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procedure  SET  BOB  (10  t  in  BOOLEAN  »■  HUE) 

is 

begin 

SET_BCIB  (CURRENT  INPUT,  TO); 
end  SET  ECHO; 


5.3.7.11  Determining  the  BOB  cn  a  terminal 

function  mb  (1BMINAL  :  in  TZIEjnre  return  BOGUAM; 

Purpose: 

This  function  returns  whether  echo  is  enabled  (HUE)  or  disabled 
(FALSE). 

TERMINAL  is  an  open  handle  on  a  terminal  file. 

Exceptions: 

USE  QOOR  is  raised  if  a  value  of  the  attribute  TERMXNALjnPE 

is  not  PAGE. 

MODE  ERROR  is  raised  if  1BMINAL  is  of  mode  CUT  FILE  or 

APPBBFTLE. 

SDmJSjaWQR  is  raised  if  TERMINAL  is  not  open. 

EEVICE_ERHCR  is  raised  ii  n  input  or  output  operation  cannot  be 
ccnpleted  because  of  a  malfunction  of  the  underlying 

systnu 

Additional  Interface: 

function  BOB  return  BCXXEAN 

is 

bsgin 

return  BC3B(CURRENT  INPUT); 
end  BOB; 


5.3.7.12  Determining  the  ranter  of  function  keys 

function  FllOTCNjaSS ( TERMINAL  :  in  FUEJRPE) 
return  NATURAL? 

Purpoee: 

Ibis  fraction  returns  the  wmxiwim  function  key  identifier  that  can 
be  returned  by  a  <ZT  operation  in  the  terminal  file  given  by 
TERMINAL. 

Parameters: 

TERMINAL  is  an  apsn  handle  cn  a  terminal  file. 
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Exceptions: 

USE_ERRDR  is  raised  if  a  value  of  the  attribute  TEFMINAL_TYPE 

is  not  PACE. 

MXt  ERROR  is  raised  if  TERMINAL  is  of  node  CUT  FILE  or 

APPEND_ETLE. 

STATUS_ERROR  is  raised  if  TERMINAL  is  not  open. 

CEVIGE_ERRCR  is  raised  if  an  input  or  output  operation  cannot  be 
ocnpleted  because  of  a  malfunction  of  the  underlying 

systsnu 

Additional  Interface: 

function  R®JCTION_KEXS  return  NATURAL 

is 

begin 

return  FUNCTXCNJCEYS (CURRENT  INPUT); 
and  FUNCTICN  KEYS; 


5.3.7.13  Reading  a  character  fron  a  terminal 

procedure  GET(TERMINAL  :  in  ETLE_TYPE; 

ITEM  :  Out  (3JARACTER; 

KEYS  :  in  Out  EUNCnCN_KEY_DESCRIProR )  ; 

Purpose: 

This  procedure  reads  either  a  single  character  into  ITEM  or  reads  a 
single  function  key  into  KEYS. 

Parameters: 

TERMINAL  is  an  open  handle  on  a  terminal  file 

ITEM  is  the  character  that  was  read. 

KEYS  describes  the  function  key  that  was  read. 

Exceptions: 

USE_ERRCR  is  raised  if  a  value  of  the  attribute  TERMINAL_TYPE 

is  not  PAGE. 

MCDEJERROR  is  raised  if  TERMINAL  is  of  node  INJETLE. 

SEATUS_ERROR  is  raised  if  TERMINAL  is  not  open. 

EEVICEJERROR  is  raised  if  an  input  or  output  operation  cannot  be 
ocnpleted  because  of  a  malfunction  of  the  underlying 
system. 

Additional  Interface: 
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procedure  <2Jr(ITEM  :  cut  CHARACTER; 

KEYS  :  in  out  FLNCTICN  KEY  DESCRIPTOR) 

Is 

begin 

GET(CURRENT_pUITVr,  ITEM,  KEYS); 
aid  GET; 


5.3.7.14  Reading  all  available  characters  from  a  terminal 

procedure  GET(TESMINAL  :  in  FTLEJTYPE? 

HEM  :  out  STRING; 

LAST  :  out  NATURAL; 

KEYS  s  in  out  ETJNCTION_KEY_EESCRIPTCMl) ; 

Purpose: 

This  procedure  successively  reads  characters  and  function  keys  into 
nm  and  KEYS  until  either  all  positions  of  HIM  are  filled  or  there 
are  no  more  characters  buffered  for  the  terminal.  Upon  oonpletian, 
LAST  contains  the  index  of  the  last  position  in  HQ4  to  contain  a 
character  that  has  been  read.  In  addition,  the  function  keys  that 
were  read  are  entered  into  KEYS. 

Parameters: 

TBMINAL  is  an  open  handle  on  a  terminal  file. 

ITEM  is  the  string  that  was  read. 

LAST  is  the  position  of  the  last  character  read  in  ITEM. 

KEYS  describes  the  function  keys  that  ware  read. 

Exceptions: 

USE_ERHOR  is  raised  if  a  value  of  the  attribute  TERMDJAL_TYFE 

is  not  PAGE. 

KXB_BRJR  is  raised  if  TBKQIAL  is  of  mode  IN _ETLE. 

STATUSJERHCR  is  raised  if  TERMINAL  is  not  open. 

□EVXOSJSRRQR  is  raised  if  an  input  or  output  operation  cannot  be 
ocnpleted  because  of  a  malfunction  of  the  underlying 

system. 

Additional  Interface: 

procedure  GET(ITEM  :  out  STRING; 

LAST  :  out  NATURAL; 

KEYS  :  in  out  FUNCTION  KEY  DESCRIPTOR) 

is 

begin 

<ZT(CURRENT  INPUT,  ITEM,  LAST,  KEY) 
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5.3.7.17  Determining  the  name  of  a  function  key 

procedure  FUNCTION  KEY  NMC  (TERMINAL  j  in  FILE  TYPE; 

KEY  namFIER  t  in  POSITIVE; 

KEY- NA^  t  Out  STRING; 

LASF  :  out  P06ITIVE); 

Purpoeet 

This  function  returns  (in  KEY_NAMJ)  the  nans  of  the  function  key 
sequence  dasi^patad  by  KEY  IDQircFIQt.  It  also  returns  the  index  of 
the  last  character  of  the  function  key  name  in  INDEX. 

Parameters: 

TEMGNAL  is  an  open  handle  on  a  terminal  file. 

KEY_IDQKnFIER  is  the  identification  timber  of  a  function  key  for 
the  terminal. 

KEYJMG  is  the  name  of  the  key  designated  by  KEY_IEDITIF1ER. 

LAST  is  the  position  in  KEY  NAME  of  the  last  character  of 

the  function  key  name.  ~ 

Exceptions: 

USE _J®RGR  is  raised  if  a  value  of  the  attribute  TEFMINALJTYPE 

“  is  not  PAGE. 

MOCEJSROR  is  raised  if  lEMXNAL  is  of  mode  Qf_EH£. 

SIKIUS_E8BCR  is  raised  if  THWINAI.  is  not  open. 

CEVICEJERROR  is  raised  if  an  input  or  output  operation  cannot  be 
ocspleted  because  of  a  malfunction  of  the  underlying 

eyetem. 

OCNSTRMOT  ERROR  is  raised  if  the  value  of  KEY  IDDfnFXBl  is  greater 

~  than  FDMCTICN_KEYS(H3MINAL) .  ~ 

Additional  Interface: 

procedure  RJNCTICN_KEY_NAME 

(KEY  IDENTIFIER  ;  in  POSITIVE; 

KEYJJAME  ;  out  STRING; 

LAST  ;  out  POSITIVE; 

is 

begin 

FUNCTION  KEY  NAFE  (CURRENT  INPUT, 

KEY  IEENTIFUR,  KEY  NAME,  LAST); 
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5.3.7.18  Deleting  characters 

procedure  EELETE  CHARACTQl  (TERMINAL  ;  In  PILE  TOPE; 

COUNT  1  in  POSITIVE  i-  1); 

Purposes 

This  procedure  deletes  COUNT  characters  on  the  active  line  starting 
at  the  active  position  and  advancing  toward  the  end'  position. 
Adjacent  characters  to  the  right  of  the  active  position  are  riiifbad 
left.  Open  space  on  the  right  is  filled  with  apace  characters.  The 
active  position  is  not  changed. 

Parameters  s 

TEFMNAL  is  an  open  handle  an  a  terminal  file. 

COUNT  is  the  nurfcer  of  characters  to  be  deleted. 

Exceptions! 

USEJERROR  is  raised  if  a  value  of  the  attribute  TERMXNALJRPE 

is  not  PAGE  or  the  value  of  COUNT  is  greater  than  the 
nutosr  of  positions  including  and  following  the 
active  position. 

MXE_ERROR  is  raised  if  TERMINAL  is  of  IN_FH£. 

STATOS_EHKCR  is  raised  if  TEEMINAL  is  not  open. 

DEVICE_EKCR  is  raised  if  an  irput  or  output  operation  cannot  be 
aanpleted  because  of  a  malfunction  of  the  underlying 
system. 

Additional  interface! 

procedure  DOEIE  CHARACTER  (COUNT  j  in  PQ6ZTIVE  i-l) 

is 

begin 

IXLERJ3]ARACIER(CXJRRTOjX7mir,  OOUNT); 
end  VBJSVEr CHARACi12<; 


5.3.7.19  Deleting  lines 

procedure  DELETE  LINE  (TBMINAL  i  in  out  FILE  TOPE; 

OCWT  i  in  POSITIVE); 

Purpose! 

This  procedure  eletsd  CCUNT  lines  starting  at  the  active 
and  advancing  toward  the  end  position.  Adjacent  lines  are  shifted 
from  the  bottom  toward  the  active  position.  OOUNT  lines  from  the 
bottom  of  the  display  are  erased.  The  active  position  is  not 
dunged. 
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Parameters! 

TB9GNAL  is  an  open  handle  an  a  terminal  file. 

COUNT  is  the  mriaer  of  lines  to  be  deleted. 

Excaptionsi 

USB  ERROR  is  raised  if  a  value  of  the  attribute  TERMINAL  TXPE 

is  not  PM3B  or  the  value  of  OOUNT  is  greater  tKan  the 
timber  of  roue  including  and  after  the  active 
position. 

MOGEJSOCR  is  raised  if  TERGNAL  is  of  mode  ZN_FH£. 

STMTJ5_ERRCR  is  raised  if  TSMXN&L  is  not  qpan. 

DEVICE _ERR0R  is  raised  if  an  input  or  output  operation  cannot  be 

oompleted  because  of  a  malfunction  of  the  underlying 

system. 

Additional  Interfacet 

procedure  dbjeie  limb  (count  i  in  positive  t-  l) 

is  ~ 

begin 

(CURRENTJOUIWr,  OOUNT); 
and  rWWELIHE; 


5.3.7.20  Erasing  characters  in  a  line 

procedure  ERASE_CSARACTER  (TERMINAL  t  in  out  FILE  TYPE; 

OOUNT  i  in  POSITIVE  1); 

Purpceet 

This  procedure  replaces  COUNT  characters  on  the  active  line  with 
apace  diameters  starting  at  the  active  position  and  advancing 
toward  the  end  position.  The  active  position  is  not  changed. 

Parameters! 

TERMINAL  is  an  opan  handle  on  a  terminal  file. 

COUNT  ie  the  timber  of  characters  to  be  erased 

Exceptions! 

USEJStROR  is  raised  if  a  value  of  the  attribute  TSRGNALJKPE 

is  not  PACE  or  the  value  of  COUNT  is  greater  then  the 

timber  of  positions  including  and  after  the  active 
position. 


MODE  ERROR 


is  raised  if  TERGNAL  is  of  mode  IN  FILE 
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SEATOS_ERROR  is  raised  if  TBMINAL  is  not  open. 

DEVICE  ERROR  is  raised  if  an  input  or  output  operation  cnmot  be 
completed  because  of  a  malfwction  of  the  underlying 
system. 

Additional  Internee: 

procedure  ERASE  CHARACTER  (COUNT  ;  in  POSITIVE  :«1) 

is 

begin 

ERASE_CHARACTER ( CUPRENTJOUTPUT ,  COUNT); 
and  ERASE  CHARACTER; 


5.3.7.21  Erasing  characters  in  the  display 

procedure  ERASE  IN  DISPLAY  (TBVQNAL  i  in  out  PHE_TVPE; 

~  SELECTION  t  in  SBECT  BUCRAXIGN); 


Purpose: 

This  procedure  erases  the  characters  in  the  satire  display  as 
determined  by  the  active  position  and  the  given  SELECTION  (including 
the  active  position).  After  erasure  sreaed  positions  have  ^mee 
characters.  The  active  position  is  not  changed. 


Parameter a; 
TEFKDJAL 

SELECTION 

Exceptions: 
USE  BOOR 


is  an  open  handle  an  a  terminal  file. 


is  the  portion  of  the  display  to  he 


is  raised  if  a  value  of  the  attribute  TBMlNALjnHS 
is  not  PASS. 


MODE  ERROR 


is  raised  if  TBMINAL  is  of  mode  IN  EHE. 


STATOSJERROR  is  raised  if  TERMINAL  is  not  open. 

DEVICE_ERROR  is  raised  if  an  input  or  output  operation  cannot  be 
“  ocnjpleted  because  of  a  malfunction  of  the  underlying 

system. 

Additional  Interface: 

procedure  ERASE  IN  DISPLAY  (SELECTION  :  in  SELECT  ENUMERATION) 

is 

begin 

ERASE_IN_DISPLAY ( CURRENT  OUTPUT,  SELECTION); 
end  ERASE  IN  DISPLAY; 
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5.3.7.22  Erasing  in  a  11ns 

procedure  ERASE  IN  LINE  (TERMINAL  i  in  out  FILE  TYPE; 

SELECTION  t  in  SE3ECT_a«*«RATICN ) ; 

Purpoast 

This  procadurs  erases  ths  characters  in  ths  activa  line  as 
determined  by  ths  activa  position  and  ths  given  SELECTION  (including 
ths  active  position) .  After  erasure  erased  positions  have  space 
characters.  The  active  position  is  not  changed. 


Parameters; 

TERMINAL 

SELECTION 


is  an  open  handle  on  a  terminal  file, 
is  the  portion  of  ths  line  to  be  erased. 


Exceptions! 

UGEJERROR 

MODE J3SCR 
9EKTOS_ERECR 
DEVICE  HOUR 


is  raised  if  a  value  Of  ths  attribute  TERMINAL  TYPE 
is  not  PAGE.  “ 

is  raised  if  TERMINAL  is  of  node  n*_FIIE. 

is  raised  if  TBMINAL  is  not  open. 

is  raised  if  an  input  or  output  operation  cannot  be 
ocspietad  because  of  a  malfunction  of  the  underlying 
system. 


Additional  Interface: 

procedure  ERASEJN  LINE  (SELECTION  :  in  SOECT  ENUMERATION) 

is 

begin 

BIASEJN  LINE  (CURRENT  OUTPUT,  SELECTION); 
end  ERASE  IN  1 LINE; 


5.3.7.23  Inserting  characters  in  a  line 

procedure  INSERT  SPACE  (TERMINAL  i  in  out  FILE  TYPE; 

COUNT  t  in  POSITIVE  *■  1); 


Purpoeet 

This  procedure  inserts  COUNT  specs  characters  into  the  active  line 
at  the  active  position.  The  character  at  the  active  position  and 
adjacent  characters  are  shifted  to  the  right.  The  rightmost 
characters  an  the  line  ay  be  loet.  The  active  position  1s  advanced 
to  the  right  0CU7T  character  poeitions. 

Parameters! 

TERMINAL 


COUNT 


is  an  open  handle  an  a  terminal  file. 

is  ths  nuihsi1  of  SPACE  characters  to  be  inserted. 
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Exceptions; 

USE_BOOR  is  raised  if  a  value  of  the  attribute  TEFMXNALJTXPE 

is  not  PAGE  or  the  value  of  OCUfT  is  greater  then  the 
ruber  of  colians  including  and  after  the  active 
position. 

MXEJBRRGR  is  raised  if  USMOOtL  is  of  mode  IN_FTLE. 

SEATOS_ERSCR  is  raised  if  TEtKQAL  is  not  open. 

DEVICE_ERSDR  is  raised  if  an  input  or  output  operation  cannot  be 
ompleted  because  of  a  malfunction  of  the  underlying 
system. 

Additional  Interface; 

procedure  INSERT  SPACE  (COUNT  t  in  POSITIVE  *-  1) 

is 

begin 

iNSERr_sPiCE(ouronffjxm|OT.  cxxjnt)? 

end  INSERT  SPACE; 


5.3. 7. 24  Inserting  lines  in  the  display 

procedure  INSERT_LINE  (TERMINAL  t  in  out  FHE_TYre; 

CXXJNT  t  in  POSITIVE  «-  1); 

Purpose; 

This  procedure  inserts  CXXJNT  blank  lines  into  the  display  at  the 
active  line.  The  lines  at  and  balov  the  top  of  the  display  are 
lost.  The  active  position  mains  unchanged. 

Parameters; 

TERMINAL  is  an  open  handle  an  a  terminal  file. 

CXXJNT  is  the  number  of  blank  Tinas  to  be  inserted. 

Exceptions; 

USEJERROR  is  raised  if  a  value  of  the  attribute  TERMINALJRPE 

is  not  PAGE  or  the  value  of  COUNT  is  greater  than  the 
nuaber  of  roue  including  and  after  the  active 
position. 

MXEJSRROR  is  raised  if  1BMXNAL  is  of  mode  IN_FLLE. 

STKXUS_ERROR  is  raised  if  TBMINAL  is  not  open. 

GEVICEJSCROR  is  raised  if  an  input  or  output  operation  aannot  be 
ocnpleted  because  of  a  malfunction  of  the  underlying 

system. 


Additional  Interface; 
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procedure  INSERT  LINE  (COUNT  t  in  F06ITIVE) 

is 

begin 

INSrai  CJNE (CURRENT_CUnVr ,  COUNT); 
end  INSE93rLINE; 


5.3.7.25  Determining  graphic  rendition  support 


function  GRAPHICJRBNDITTGN  SUPPORT  (TQMINAL  t  in  FILE  TYPE; 

RDDITIOH  s  in 


GRAPHIC  RDDITICN  ARRAY) 


return  BOOLEAN; 


Purpose; 

This  fraction  returns  TRUE  if  the  RSDITICN  of  oadained  graphic 
renditions  is  supported  by  TERMINAL;  otherwise  it  returns  FALSE. 


Parameters  i 

TERMINAL  is  an  open  handle  an  a  terminal  file. 

RENDITION  is  a  ocnbination  of  graphic  renditions. 


Exceptional 
USE  ERROR 


is  raised  if  a  value  of  the  attribute  TEEMINALJKPE 
is  not  PAGE. 


HOLE  ERROR 


is  raised  if  TERMINAL  is  of  mode  IN  FILE. 


SBOUBJRR*  is  raissd  if  TERMINAL  is  not  open. 

OEVKXJERROR  is  raised  if  an  input  or  output  operation  cannot  be 
ompleted  because  of  a  malfunction  of  the  underlying 

system. 


Additional  Interface: 

fraction  GRAPHIC  RENDITION  SUPPORT 

(REtOmCN  in  GRAPHIC  ltaOinON_ARRAY) 
return  BOOLEAN 

is 

begin 

return  GRAPHIC  RENDITION  SUPPORT  (CURRENT  OUTPUT,  RENDITION); 
end  GRAPHIC  RENDITION  SUPPORT; 
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5.3.7.26  Selecting  the  graphic  rendition 

procedure  SELECT_GRAH!IC_RENDrriCN 

(TERMINAL  t  in  FILE  TYPE; 

RENDITION  :  in  GRAPtIlC_ROBrnCN  ARRAY 
*-  DHWJLT  GRAPHIC  RENDITION); 


Purpose: 

This  procedure  sets  the  graphic  rendition  for  subsequent  characters 
to  be  PUT. 


Parameters: 

TERMINAL  is  an  open  handle  an  a  terminal  file. 

REH3ITICN  is  the  graphic  rendition  to  be  used  in  subsequent 

EVTs. 


Exceptions: 
USE  ERROR 


MOOE_ERROR 
STATUSJERROR 
DEVICE  ERROR 


is  raised  if  a  value  of  the  attribute  TESMXNALJRPE 
is  not  PAGE  or  the  selected  graphic  renditions-  are 
not  supported  by  TERMINAL. 

is  raised  if  TBMXNAL  is  of  mode  IN_FHZ. 

is  raised  if  TERMINAL  is  not  open. 

is  raised  if  an  input  or  output  operation  cannot  be 
ocnpleted  because  of  a  malfunction  of  the  underlying 
system. 


Additional  Interface: 


procedure  SHJCT  GRAPHIC  RENDITION 

(RQCmCN  :  in  GRAPHIC  RENDITION  ARRAY 

DEFAULT  GRAPHIC  RENDITION) 
is  - 

begin 

SELBCT_GRAFHIC  ROBITICN (CURRENT  OUTPUT,  RENDITION) ; 
end  SELECT  GRAPHIC  1 RENDITION; 


5.3.8  Package  CAI S_EURM_TERMINAL 

This  package  provides  functionality  for  manipulating  a  form  terminal 
(e.g.,  an  IBM  327x  terminal).  A  form  terminal  consists  of  a  single 
device  (inasmuch  as  a  progranmer  is  ooncerned). 

The  scenario  for  usage  of  a  form  terminal  has  two  active  agents:  a 
process  and  a  user.  Each  interaction  with  the  form  terminal  consists  of 
a  three  step  sequence.  First,  the  process  creates  and  writes  a  form  to 
the  terminal.  Second,  the  user  nedifies  the  form.  Third,  the  process 
reads  the  modified  form. 
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A  farm  in  a  two-dimensional  matrix  of  character  positions.  The  rows  of 
a  form  are  indexed  by  POSITIVE  nmbera  starting  with  row  1  at  the  top  of 
the  display.  The  columns  of  a  form  are  indexed  by  POSITIVE  nmfcers 
starting  with  oolimn  1  at  the  left  aide  of  the  form.  The  position 
identified  by  row  1,  oolimn  1,  is  called  the  starting  position  of  the 
form.  The  position  with  the  highest  row  and  oolimn  indices  is  called 
the  end  position  of  the  form. 

The  position  at  which  an  operation  is  to  be  performed  is  called  the 
"active  position."  The  active  position  is  said  to  advance  toward  the  end 
position  of  the  form  vfoen  the  indices  of  its  position  are  incremented. 
The  oolimn  index  is  incremented  isrtil  it  attains  the  highest  value 
permitted  far  the  form.  The  next  position  is  determined  by  incrementing 
the  row  index  of  the  active  position  and  resetting  the  column  index  to 
1. 

A  form  is  divided  into  "qualified  areas."  A  qualified  area  identifies  a 
contiguous  groif>  of  positions  that  share  a  council  set  of 
characteristics.  A  qualified  area  begins  at  the  position  designated  by 
an  "area  qualifier"  and  ends  at  the  position  preceding  the  next  area 
qualifier  toward  the  end  of  the  farm.  Depending  on  the  form,  the 
position  of  the  area  qualifier  may  or  may  not  be  considered  to  be  in  a 
qualified  area.  The  characteristics  of  a  qualified  area  consist  of  such 
things  as  protection  (frcm  modification  by  the  user),  display  renditions 
(e.g.,  intensity),  and  permissible  values  (e.g. ,  nuneric  only, 
alphabetic  only).  Each  position  in  a  qualified  area  contains  a  single 
printable  ASCII  character. 


5. 3.8.1  Types,  subtypes,  constants,  and  exceptions 

type  AHEA_INTHBITY  is 
(HONE, 

MORAL, 

HIGH)  7 

type  AHEA_PRDIBCTICN  is 
(UNPHLFm.m>, 

PROTECTED)? 

type  ASEA_INPUr  is 

(GRAPHIC  CHARACTERS, 

MWERICS, 

ALEHAEienCS); 

type  AREA  VALUE  is 
(NO  FILL, 

Pitt  WnH_ZEHOES, 

pniTwira jspaces  ) ; 

type  FORM  TOPE 

(SIZE  ”  :  PCSmCNTYPE; 

AREA  QUALIFIER  REQUIRES  SPACE  t  BOOLEAN) 
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is  private; 

subtype  FUZJIYPEia  CMS_IOjXNIKXi.ETLE_TVPE; 

subtype  PRINIABL£_CHARACTTR  is  CHARACITO  range  *  *  .. 

area  INTENSITY  indicates  the  intensity  at  vbicb  the  characters  in  the 
area" should  be  displayed  (NCNE  indicates  that  characters  are  not 
displayed).  AREA_PSOTCCTTCN  specifies  vbether  the  user  can  modify  the 
contents  of  the  area  when  the  form  has  been  activated.  AT *  I'WT 
specifies  the  valid  dmractars  that  nay  be  entered  by  the  -se r; 
GRAPHIC J33ARACTERS  indicates  that  any  printable  character  may  be 
entered.  AREA  VALUE  indicates  the  initial  value  that  the  area  should 
have  when  activated;  NOJFILL  indicates  that  tha  value  has  been 
specified  by  a  previous  PUT- statement. 

USEJERRCR  t  exception  renames  CAIS_IO  B<CEPTICMS.USE_ER»CR; 
MXE_ERROR  :  exception  renames  CAISJOTPOCEPTIOMB  .MXC_ERROft; 
STATUS  ERROR  >  exception  revet—  CAIS~* IO~i PCCEPT1CMS.  STATUS  ERROR ; 
LATOUT^RRDR  j  exemption  renames  CAIS^ro^jSOagTICHB .  IATOOT J5SCR ; 
OEVICE_ERROR  t  exemption  renames  CAIS~IO~ECCmTCIJS .  CEVICE~ERRCR ; 

USE  _ERROR  is  raised  if  an  operation  is  attssptsd  that  is  not  possible 
far  reasons  that  depend  on  the  characteristics  of  the  external  file. 
M30EJSRR0R  is  raised  by  an  attaspt  to  read  fron  a  file  of  mode  <XJT_FH£ 
or  write  to  a  file  of  mode  IN  FH£.  STATUE  ERROR  is  raised  if  the 
handle  an  the  terminal  file  Is  not  open.  EEVICTMaWDR  is  raised  if  an 
input  or  output  operation  cannot  be  completed  because  of  a  nalfwcticn 
of  the  vmderlying  system.  IATOOTJERROR  is  raised  by  an  attmipt  to  set 
colunn  or  row  ambers  in  excess  of  pacified  maximal  values. 


5. 3. 8. 2  Determining  the  ramtoar  of  function  keys 

function  FUNCTTCNJCErS  (TERMINAL  i  in  EnETOPE) 
return  NATURAL; 

Purpose; 

This  function  returns  the  murimin  value  that  can  be  returned  by  the 
fwetion  TERMrNATICN_KEy. 

Panmaters; 

TEWONAL  is  an  open  handle  on  a  terminal  file. 

Exceptions; 

USE_ERHOR  is  raised  if  a  value  of  the  attribute  TEHM3NAL_T¥PE 

”  is  not  FORM. 

MODE  ERROR  is  raised  if  TERMINAL  is  of  mods  CUT  FILE  or 

APPQCJTXE. 

SEATUS_ERROR  is  raised  if  TERMINAL  is  not  open. 
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DEVICE_E2?ROR  is  raised  if  an  input  or  output  operation  cannot  be 
ocnpleted  because  of  a  malfunction  of  the  underlying 
system. 

Additional  Interface: 

function  FUNCITCNJCEYS  return  NATURAL 
is 

begin 

return  FUNCTICN_KEYS ( CURRENT  INPUT); 
end  FUNCTION  KEYS;  ~ 


5.3.8. 3  Opening  a  farm 
procedure  OP£N 

(FCSM  :  out  FOFM_TYPE; 

SIZE  :  in  POSITION  TYPE; 

AREA  QUALIFIER  REQUIRES  SPACE  :  in  BOOLEAN)? 


Purpose: 

This  procedure  opens  a  FORM  of  the  specified  size  to  be  used  with  a 

form  terminal. 

Parameters: 

FORM  is  the  form  to  be  opened  far  nanipulation. 

SIZE  indicates  the  size  of  form  to  be  opened  (which  should 

correspond  with  the  size  of  the  form  terminal  on 
which  it  will  be  activated). 

AREA_CUALIFIER_RBQUIRES_SPACE  indicates  whether  the  area  qualifier 
requires  space  on  this  form  (i.e.,  the  position  in 
%Aiic±i  the  area  qualifier  is  defined  may  not  be  used 
for  the  display  of  data). 


Exceptions:  none 


5. 3.8.4  Determining  whether  a  form  is  open 

function  IS  CPEN(FORM  :  in  FORM  TYPE)  return  BOOLEAN; 


Purpose: 

This  function  returns  TRUE  if  the  FORM  has  been  opened;  otherwise 
it  returns  FALSE. 


Parameters: 

FORM  is  the  form  being  queried. 

Exceptions:  none 
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5. 3.8. 5  Defining  a  qualified  area 

procedure  DEFINE_QUALIFIJ3)_AREA 
(EOSM  i— in  out  FC«4  TYPE; 

INTQBny  J  in  ASEA^WIBJSITY  s«  NORMAL; 

pRcrncncN  t  in  ARDTpRcrrscnaii  t-  protected? 

INPUT  t  in  ARSnoaur  :-  GWMTOC  CHARACTERS; 

VALUE  :  in  AR£A~VALUE  *-  »0_FILLT; 

Purposes 

this  procedure  pi**’’—  an  area  qualifier  with  the  designated 
attributes  at  the  active  position.  A  qualified  area  consists  of  the 
character  positions  between  two  area  qualifiers.  The  area  is 
qualified  by  the  area  qualifier  that  precedes  the  area.  A  qualified 
area  may  or  may  not  include  the  position  of  its  area  qualifier. 

Parameters: 

FCXM 

INTOEmr 


PROTECTION 

INPUT 


VALUE 

Exceptions: 

STATUS  ERROR  is  raised  if  FORM  is  not  open. 


5. 3. 8. 6  Removing  an  ares  qualifier 

procedure  RDOVE  AREA_0UAL1PIER 

(FO*W  ~t  in  out  FORMJTYPE); 

Purpose: 

This  procedure  removes  an  area  qualifier  from  the  active  position. 
Parameters: 

FORM  is  the  open  form  from  which  the  qualified  area  is  to 

be  removed. 

Exceptions: 

USE_ERROR  is  raised  if  the  active  position  doss  not  have  an 

area  qualifier. 

STATUS  ERROR  is  raised  if  FORM  is  not  open. 


is  an  open  fora. 

indicates  the  intensity  at  which  the  qualified  area 
is  to  be  displayed* 

indicates  the  protection  for  the  qualified  area. 

indicates  the  permissible  input  characters  for  the 
qualified  area. 

indicates  the  initial  value  of  the  qualified  area. 
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5. 3.8.7  Changing  the  active  poeiticn 

procedure  SEX  POSITION  (FORM  t  in  out  FORM  TYPE; 

POSITION  s  in  POSITICN_TYPE); 

Puxpoee: 

This  procedure  indicates  the  poeiticn  on  the  fora  that  is  to  became 
the  active  position. 

Parameters: 

FORM  is  the  fora  on  vftvich  to  change  the  active  position. 

POSITION  is  the  new  active  position  on  the  form. 

Exceptions: 

STOnjS_ERROR  is  raised  if  FORM  is  not  open. 

IAKXTT_ERROR  is  raised  if  POSITION  does  not  identify  a  position  on 

FORM. 


5. 3.8.8  Moving  to  the  next  qualified  area 

procedure  NE3CT_QQALIFTED_AREA  ( FORM  :  in  out  FOHMTYPE? 

OCUNT  :  in  POSITIVE  :«  1); 

Purpose: 

This  procedure  moves  the  active  position  CDCNT  qualified  areas 

ttMand  the  end  of  the  fora. 

Parameters: 

FORM  is  an  open  fora. 

COUNT  is  the  rasher  of  qualified  areas  the  active  position 

is  to  be  advanced. 

Exceptions: 

STATUSJQSOR  is  raised  if  either  FORM  is  not  open  or  FORM  has 
fewer  than  OCUNT  qualified  areas  after  the  active 
position. 
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5. 3.8.9  writing  to  a  form 

procedure  PUT  (FORM  :  in  out  FORM  TYPE; 

ITEM  t  in  PRZN&BEZJSMWCTER); 

Purpose: 

This  procedure  placee  ITEM  at  the  active  poeiticn  of  FOEM  and 
advances  the  active  position  one  position  tonzd  the  end  position. 

If  the  active  position  is  the  and  position,  the  active  position  is 
not  duuiged. 

Parameters: 

FORM  is  an  open  form. 

ITEM  is  the  character  to  be  written  to  the  form. 

Exceptions: 

USE  ERROR  is  raised  if  the  active  position  contains  an  area 

qualifier  arxl  AREA_dUALIFiro_RE3CIUIRES_SPACE  of  FCSM 
was  set  to  TRIE.  ~ 

STATUS  ERROR  is  raised  if  FO CM  is  not  open. 


Additional  interfaces: 

procedure  POT  (FCSM  :  in  out  FORM  TYPE; 

ITEM  :  in  STRING) 

is 

begin 

far  INDEX  in  ITH*' FIRST  ..  ITEM' LAST  loop 

PUT(roPM,  ITEM  (INDEX) ) ;  —  Writs  a  single  character 
end  loop; 
end  POT; 


5.3.8.10  Erasing  a  qualified  area 

procedure  BtASE  AREA. 

(FORM  :  in  out  FCSMJTXPE) ; 

Purpose: 

This  procedure  places  space  dmracters  in  all  positions  of  the  area 
in  which  the  active  position  is  located. 

Parameters: 

FORM  is  an  open  form. 

Exceptions: 

STATOS_ERROR  is  raised  if  FORM  is  not  open  or  no  area 
qualifiers  have  been  defined  fcr  FORM. 
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5.3.8.11  Erasing  the  form 


procedure  H»SE  FORM 

(FORM  t  in  out  FOfMJHPE); 

Purpose: 

this  procedure  removes  all 
characters  in  all  poeiticne. 


qualifiers  and  places  SPACE 


FORM  is  an  open  form. 

Exceptions: 

STATUS  ERROR  is  raised  if  FORM  is  not  open. 


5.3.8.12  Activating  a  form  on  a  terminal 

procedure  ACTIVATE  (TESMIMAL  t  in  FXLEJHPEr 
FORM  «  in  out  FORMJKPEh 

Purpose! 

This  procedure  activates  the  form  an  the  terminal.  The  terminal 
display  is  mortified  to  reflect  the  contents  of  the  form.  When  the 
user  of  the  fr—urfrmi  enters  a  termination  key  the  mortified  form  is 
returned.  Only  the  unprotected  areas  of  the  form  may  be  modified  by 
the  user. 


Parameters! 

TERMINAL 


STATUS  ERROR 


is  an  open  handle  an  a  terminal  file, 
is  an  open  form. 


is  raised  if  a  value  of  the  attribute  THMINALJRPE 
is  not  FOM.  It  is  also  raised  if  either  the  size  of 
the  form  is  not  ocnpatible  with  the  terminal  (i.e. 
the  sixes  differ  or  the  area  qualifier  requires  apace 
on  the  terminal,  but  not  an  the  form. 

is  raised  if  either  TERMINAL  is  not  open  or  FORM  is 
not  open. 


vZnO.v:-.’-/ 


v  ••  % 


3-202  U 


PROPOSED  MUr-STO-CAIS 
31  OCT  1964 

5.3.8.13  Reading  from  a  form 

procedure  GET  (FORM  t  in  out  FORMTWE;  _ 

vrm  t  out  PRUTCABIZ  CHARACTER); 


Purpose: 

This  procedure  reeds  a  character  from  POfM  at  the  active  position. 
Advances  the  active  position  forward  one  position  (unless  the  active 
position  is  the  end  position) .  An  area  qualifier  (on  a  form  on 
which  the  area  qualifier  requiree  space)  is  read  as  the  SPAOS 
character. 

Parameters: 

FORM  is  an  open  form. 

ITEM  is  the  character  that  was  read. 

Exceptions: 

SEMUS_ERHCR  is  raised  if  FORM  is  not  open. 

Additional  interfaces: 

procedure  (XT  (FORM  i  in  cut  FORM  TYPE; 

ITEM  >  out  SROSb) 

is 

begin 

for  HCEX  in  Firai'FCRST  ..  ITEM* LAST  loop 

GET(FORM,  ITGM(imSC));  —  Read  a  single  character 
end  loop; 
end  <ZT; 


5.3.8.14  Determining  changes  to  a  font 

function  IS_EORM_UPOA!IED ( FORM  t  in  F0RM_TCPE)  return  BOOLEAN; 
Purpose: 

this  function  returns  HUE  if  the  value  of  any  position  on  the  form 
was  modified  during  the  last  activate  operation  in  which  the  form 
was  used;  otherwise  it  returns  FALSE. 

Parameters: 

FORM  is  an  open  form. 

Exceptions: 

STATUS  ERROR 


is  raised  if  FORM  is  not  open 
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5.3.8.15  Determining  the  termination  key 

function  THWINATICN_KEY ( PC4W  i  in  TOSMJIVPE)  return  NATURAL; 
Purpoeet 

This  function  returns  a  number  that  indicates  vtoich  (implementation 
dependent)  key  terminated  the  ACTIVATE  FORM  procedure.  A  value  of 
zero  indicates  the  normal  termination  Iwy  (e.g.,  the  QJIER  key). 

Parameters: 

FORM  is  an  open  form. 

Exceptions: 

STATOSjaRROR  is  raised  if  FORM  is  not  open. 


5.3.8.16  Determining  the  size  of  a  farm/ terminal 

function  SXZEttOBM  :  in  FORM  TYPE)  return  P06ITICK  TYPE; 

function  SIZEdSEIMZNAL  :  in  PZUQCDD)  return  POSnTCNJTYPE; 

Purpose: 

These  functions  return  the  position  of  the  last  oolum  of  the  last 
row  of  the  farm/ terminal. 

Parameters: 

FORM  is  an  open  farm. 

TERMINAL  is  an  open  handle  an  a  terminal  file. 

Exceptions: 

USE_ERHOR  is  raised  if  a  value  of  the  attribute  TEHMINAL_TYPE 

is  not  FORM. 

M3DE_H®0R  is  raised  if  TERMXNAL  is  of  mode  INJPXLE. 

STA3TJS_ERRCR  is  raised  if  FOPM/TERKINAL  is  not  open. 

EEViaBJSRHDR  is  raised  if  an  input  cr  output  operation  cannot  be 
aanpleted  because  of  a  malfunction  of  the  underlying 
system. 

Additional  Interface: 

function  SIZE  return  POSITION  TYPE 

Is 

begin 

return  SIZE(CURHEOT_CUTWr); 
end  SIZE; 


PROPOSED  MII/-SID-CAIS 
31  OCT  1964 


5.3.8.17  Determining  if  the 


qualifier  requires 


function  AREA  QUALIFIER  REQUIRES  SPACE 
(EOSM  *  in~FOSM_T¥PET 
return  BOCXEAN; 

function  AREA_QUALIFIER_REQUIRES_SPACE 
(TSVUNAL  T  in  FUEJWPE) 
return  BOOLEAN; 

Purpose* 

these  functions  return  TRUE  if  the  area  qualifier  requires 
the  form/ terminal;  otherwise  returns  FALSE. 


Parameters: 

FORM 

TERMINAL 

Exceptions: 


MXE  ERROR 


is  an  open  form. 

is  an  open  handle  on  a  terminal  file. 


is  raised  if  a  value  of  the  attribute  tSMXNALJKPE 
is  not  REM. 

is  raised  if  THMINAL  is  of  mode  IN  FH2. 


STASUS_ERRCR  is  raised  if  POBM/TSMINAL  is  not  open. 

EEVICE_ERROR  is  raised  if  an  input  or  output  operation  aannot  be 
ocnpleted  because  of  a  malfwcticn  of  the  underlying 
eyetam. 

Additional  Interface: 

function  AREA_QUAL2FIER_RBQUXEES  SPACZ  return  BOOLEAN 

is  ~ 

begin 

return  AREA  QUALIFIER_RBQUIRES  SPACE  (CURROfT  OUTPUT); 
end  AREA  QUALIFIER  REQUIRES  SPACE;-' 


5.3.9  GAIS  GENERAL  TAPE 


This  package  provides  interfaces  far  the  support  of  input  and  outpur 
operations  an  both  labeled  and  unlabeled  magnetic  tapee.  Interfaces  for 
labeled  tapes  are  designed  with  careful  consideration  of  level  II  of 
CANSI  78]. 

The  CMS  supports  the  transfer  of  information  to  and  from  a  single  tape 
voluns.  The  CAIS  supports  the  transfer  of  source  programs.  Data 
transferred  to  and  from  tapes  my  oonsist  of  the  following  characters: 


Characters 


ail  printable  characters 


Representation  of  Characters 
corresponding  characters 
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horizontal  tab 
vertical  tab 
oarriaga  return 
lina  faad 
font  faad 
and-of-file 


ASCII  .HT 

ascii,  vr 

ASCII  .CR 
ASCII .LF 
ASCH.EF 

zero  or  more  NULLa  followed 
inmadiataly  toy  a  tape  nark. 


Uaa  of  othar  characters  is  not  defined  with  the  exception  of  NULL  which 
is  ueed  in  the  andtaf-file  definition,  the  end-of-line  terminator  is 
the  line  feed.  the  and-of-page  terminator  ia  the  form  feed.  An 
and-of-page  terminator  must  be  preceded  by  an  end-of-line  terminator. 
An  andtaf-file  must  be  preceded  by  an  and-of-page  terminator. 

To  uee  a  tape  drive,  a  handle  on  the  drive  must  be  obtained  (eee  OPEN  in 
Section  *(5.3.4.3.the  first  tine  a  tape  is  used,  it  oust  be  initialized 
either  as  a  labeled  tape  or  as  an  unlabeled  tape.  All  initialized  tapes 
nay  be  moulted  aa  unlabeled  tapes;  however,  only  initialized  labeled 
tapae  nay  be  Mounted  aa  lahalad  tapes,  the  eenentice  of  bath 
initializing  and  moulting  isply  the  loading  of  the  tape.  Once  a  tape 
has  bean  mounted,  CAISJEBOMCO  routinaa  are  ueed  to  get  infatuation  to 
and  from  the  tape.  ” 

Whan  information  transfer  is  acspletad,  the  tape  ia  dismounted  or 
rewound  using  either  the  UNLOAD  or  NDJJNL3AD  option.  If  UNLOAD  is 
choaen,  the  tape  is  ocnpletely  rewound.  If  NO_UNLOAD  is  choeen,  the 
tape  ia  rewound  to  the  beginning  of  the  tape  and  may  be  remounted. 

Once  a  tape  is  uiloedad,  another  tape  nay  be  mounted.  Whan  the  user  is 
finished  utilizing  the  drive,  he  closes  the  file  handle  on  the  drive 
(see  Section  5.3.4). 


The  following  ia  the  format  of  files  on  unlabeled  tape  where  an 
represents  a  tape  mark  and  BUT  ia  the  beginning  of  the  tape. 


BOT  file  *  file  *  ...  •  file  ** 


The  following  ia  the  fbunal  of  files  an  labeled  tape  where  an 
repreeenta  a  tape  nark,  BOT  ia  the  beginning  of  the  tape,  VOL  is  the 
Volume  Header  Label,  HU  is  the  Pile  Header  label,  and  EOF  is  the 
Bid-of-Pile  label. 


BOT  VOL  BH  *  file  *  BOP  *  BCR  *  file  *  DCF  *  ...  *  HDR  *  file  *  EOF  ** 


(If  a  labeled  tape  is  moulted  as  an  unlabeled  tape,  then  each  label 
grotqp  ia  aonaidared  to  be  a  file.) 
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5. 3.9.1  Types,  subtypes,  oonstants,  and  exceptions 


type 


type 

type 

type 


5EATUS  is 

( STAPT_OP_TAPE ,  —  at  beginning-of-tapa  reflector  nark 

ETDCEjfiPE,  —  at  the  end-of-tape  reflector  nark 
TAPE  MRKJEAD,  —  tape  mark  has  just  besn  read 
DOUfiSj^TAPE_MARK,  —  delimits  the  logical  end  of  tape 
CRIVE_REAI7Y7  — •  device  is  on  line 

M0Uflfi>,  —  tape  has  been  mounted 

—  tape  is  a  labeled  tape 

—  write  ring  is  in 
STATUS- ARRAY  is  array  (STATUS)  of  BOOLEAN; 

LOAD  TYPE  is  (UNLOAD,  NO  UNLOAD); 

DENSITY  TYPE  is  (DQ6ITY- 800,  DENSITY  1660,  DENSITY  6250); 


WRITE  ENABLE)); 


STATUS  ARRAY  contains  current  information  about  a  tape  drive.  LQAD_TYPE 
determines  vftether  a  rewind  will  stop  at  the  beginning-of-tape  reflector 
mark  or  rewind  all  of  the  wey. 


subtype  vau MS  JTRZNQ  is  9TRZNS(1..6); 
autotype  FHJE_sftUNG  is  STRING (1..  17); 
subtype  NAM  STRING  is  STRING; 
subtype  TAPEJKPE  is  CAIS.FILE  TYPE; 


MXE_ERHOR  t  exception 
STATUSJERROR  <  exception 
CEVICEJERROR  t  exception 
USEJERROR  i  exception 


CAZS  10  EXC1STCGNS  .MODE  ERROR; 
CAIS- IcTeXCEPTICNS  .  STATUS  ERROR; 
CMS~ 10  EXCEPTIONS .  DEVICE- ERROR; 
CMS- I0— SaCEPTICNS.USE  ERROR; 


VCXUCJ9IRINS  and  FHE_SIRIN3  both  have  the  syntax  of  an  Ada  identifier. 
NAte_STRZNG  is  used  for  the  external  nans  of  a  tape,  i.e.,  the  nan* 
written  an  the  tape  container.  The  file  type  TAPE  TYPE  is  used  for 
controlling  all  operations  on  tape  drives. 

MTCE  ERROR  is  raised  by  an  atteapt  to  read  from  a  file  of  mode  COT  FILE 
or  wits  to  a  file  of  mode  IN  FILE.  STATUS_ERHOR  is  raised  if-  the 
handle  on  the  terminal  file  Is  not  open.  DEVICE  ERROR  is  raised  if  an 
input  or  output  operation  aarnot  be  ampleted  because  of  a  malfunction 
of  the  ixider lying  system.  USE  BBCR  is  raised  if  an  operation  is 
attempted  that  is  net  possible  for  reasons  that  depend  on 
characteristic*  of  the  external  file. 
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5. 3. 9. 2  Mounting  an  unlabeled  tape 

procedure  IMMHB)  MOUNT  (TOPE  DRIVE:  in  TAPE  TYPE; 

TAPE  NAtC:  in  NMe- STRING)  ; 


Purpose: 

This  procedure  moults  a  tap*  When  «xt*mal  nan*  la  TOPEJMC  on  th* 
driv*  idantifiad  by  TAPE  DRIVE  and  seta  the  atatua  of  — MCUNTH5  to 
TRUE. 

The  tap*  ia  stopped  at  th*  beginning  of  the  tap*.  TAPE_MARK_READ  ia 
mat  true.  Thia  procedure  dvecks  for  a  write  ring  anl  a*ta 
WRTTEJBiMLH)  accordingly.  Thia  procedure  seta  LABEL®  to  FALSE. 

Parameters: 

TAPE_DRIVE  ia  an  open  handle  an  a  tape  drive  file. 

TAPE_NMC  ia  an  external  label  which  identifies  the  volume  to 

"*  be  mounted. 


Exceptions: 

MXEJ3BCR 

SEATUS_nWOR 
DEVICE  ERROR 


USE  ERROR 


is  raised  if  the  file  mode  of  the  xMFE  DRIVE  is 
INFILE. 

ia  raised  if  TAPE_DRTVE  ia  not  open. 

is  raised  if  an  input  or  output  operation  cannot  be 
aoepleted  bemuse  of  a  malfunction  of  the  underlying 

system. 

ia  raised  if  an  attanpt  is  made  to  mount  a  mounted 
tape  or  an  attmqpt  is  Bade  to  mount  a  tape  that  is 
not  yet  initial iaed. 


5. 3. 9.3  Mounting  a  labeled  tape 


procedure  LABELS)  MOUNT  (TAPE  DRIVE:  in 

MXJUBe  ID:  in 
TAPE  NMC:  in 


TAPE  TOPE; 
VXUC  STRING; 
NAME  STRING); 


Purpose: 

This  procedure  mounts  a  labeled  tape  whose  external  name 
TAFE_NAME  on  the  drive  identified  by  TAPEJ3RIVE.  It  dwdes  to 
that-  the  first  block  on  the  TOluma  is  a  Volume  Header  label  (MX 
See  Table  XIV).  The  M3UUK  ID  in  the  parameter  list  must  match 
volume  Identifier  in  the  VdTmm  Header  label  an  the  tape. 

The  tape  is  stopped  at  the  beginning-of-tape  reflector  mark. 


TAPE  DRIVE 


is  an  epan  handle  cn  a  tape  drive  file. 
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VOUXC  ID  is  the  name  which  identifies  volute;  it  oust  match 

the  none  in  the  volute  header. 

Exceptions  t 

MXE  ERRC »  is  raised  if  the  file  node  of  the  TAPE  DRIVE  is 

DJJILE. 

STATUSJ5RRCR  is  raised  if  TAPE_DRIVE  is  not  open. 

EEVICE_ERHCR  is  raised  if  an  input  or  output  operation  cannot  be 
oanpleted  because  of  a  malfunction  of  the  underlying 
system. 

USE_EKBDR  is  raised  if  an  attenpt  is  mads  to  nount  a  mounted 

tape,  if  the  V*XJUMB_ID  does  not  match  the  volume 
identifier,  if  an  attenpt  is  made  to  mount  a  tape 
that  is  not  yet  initialized,  or  if  an  attenpt  is  made 

to  mount  an  unlabel  art  tape. 


5. 3. 9.4  Dismounting  a  tape 

procedure  DISMOUNT  (TAPE  DRIVE;  in  TAFE_TYPE; 

LOAD:  in  ICADJKPE  :«  UNLOAD); 

Purpose: 

This  procedure  dismounts  the  tape  on  the  drive  identified  by 
TAPE_DRIVE  and  sets  the  status  Of  DRIVEJCADT  to  FALSE.  If  the 
parameter  LOAD  has  the  value  NOJXBXAD,  than  the  tape  is  left  at  the 
beginning-of-tape  reflector  marie  and  the  status  of  STAFT_CF_TAPE  is 
set  THJE;  otherwise,  the  tape  is  unloaded.  Dismounting  a 
dismounted  tape  has  no  effect. 

Parasmters: 

TAPE_ERIVE  is  an  open  handle  an  a  tape  drive  file. 

LOAD  determines  whethsr  the  tape  will  be  unloaded  or  left 

at  the  beginning-of-tape  nark. 

Exemptions: 

MXE  QQCR  is  raised  if  the  file  mode  of  the  TAFE_DRIVE  is 

INJPUE. 

SEATUS_naoR  is  raised  if  TAPE_DRIVE  is  not  open. 

DEVICE  JERK,*  is  raised  if  an  input  or  output  operation  cannot  be 

acspleted  because  of  a  malfunction  of  the  underlying 
systam. 
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5. 3.9.5  Detannining  tape  status 

function  TAPE_SI3OTJS  (TAPEJJRIVE:  In  TAPEJTXPE) 
return  STATOS_ARRAY;  — 

Purpose! 

This  procedure  obtains  current  tape  statue  infcotetion.  Hois 
procedure  may  be  invoked  vAiile  the  calling  process  has  an  open 
handle  on  the  tape  drive. 

Parameters: 

TAPE_DRIVE  is  an  open  handle  an  a  tape  drive  file. 


Exceptions: 

MDOEJSROR  is  raised  if  the  file  node  of  the  TAPE  DRIVE  is 

IN  FILE. 


SDmS_ERROR 
DEVICE  ERROR 


is  raised  if  TAPEJDRIVE  is  not  open. 


is  raised  if  an  input  or  output  operation  cannot  be 
oanpieted  because  of  a  malfunction  of  the  underlying 


5. 3. 9.6  Skipping  tape  narks 

procedure  SKtPJTAPE  (ARKS  (TAPEJDRIVE:  in 
“  NUMB3U  in 


TAPETXPE; 

INTEGER:-!); 


Purpose: 

This  procedure  provides  a  method  of  Skipping  over  taps  marks.  A 
positive  NUMBER  indicates  forward  Skipping,  vAila  a  negative  ULMER 

indicates  backward  skipping.  If  NUMER  is  zero,  no  operation  is 

--  .  - 

perrarxnea. 

Unless  HMER  is  zero,  the  status  of  TAPE_M\FKJE031D  is  TRIE  after 
this  procedure.  If  two  adjacent  tape  marks-  are-  encountered,  the 
statue  of  DCUBLEJEAFEJMARK  is  set  THJE  and  the  tape  is  stopped 
following  the  second  tape  mark.  If  the  end-of-tape  (EOT)  reflector 
mark  is  encountered,  ENDJDFJEAPE  is  set  TRIE.  If  the 
beginning-of-tape  (BOT)  reflector- nark  is  encountered,  the  tape  is 
stopped  at  the  BCfT  reflector  mark  and  the  status  of  START  OF  TAPE  is 
set  TRJE. 

Parameters: 

TAPEJDRIVE  is  an  opan  handle  on  a  tape  drive  file. 

NUMBER  is  the  rusfeer  of  tape  marks  to  skip  and  the  direction 

of  movement. 

Exceptions: 

MXEJBOCR  is  raised  if  the  file  mode  of  the  TAPE  DRIVE  is 
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IN_FIL£. 

STATUS_ERRDR  is  raised  if  TAPE_DRIVE  is  not  open. 

EEVKE_ERROR  is  raised  if  an  input  or  output  operation  cannot  be 
oanpleted  because  of  a  malfunction  of  the  underlying 
systan. 

Notes: 

Nothing  beyond  a  double  tape  nark  is  accessible. 

If  the  status  of  END_QF_TAPE  is  set  TFUE,  then  it  retrains  TRUE  until 
the  and-of-tape  reflector  nark  is  passed  in  the  opposite  (reverse) 
direction. 


5. 3.9.7  writing  a  tape  nark 

procedure  »MTE_TAPE_MARK  (TAPE  DRIVE:  in  TAPE  TYPE; 

Nt*fiOfc  in  POSITIVE  1); 

Purpose: 

This  procedure  writes  NIM3ER  consecutive  tape  narks  an  the  tape 
which  is  mounted  on  the  drive  identified  by  TAPE_DRIVE.  The  tape  is 
stopped  following  the  last  tape  nark  written. 

A  single  tape  mark  is  written  following  eech  file  except  the  last 
file  an  the  tape  which  is  followed  by  a  double  tape  nark.  For  the 
CAIS,  a  file  on  a  magnetic  tape  is  either  a  text  file  or  a  label 
group  vftere  a  label  group  can  be  one  of  the  following:  a 
Volume-Header  label  and  a  File-Header  label,  or  a  File-Header  label, 
or  an  Qid-of-File  label. 

If  a  single  tape  nark  is  written  the  status  of  TAPE_MARK  READ  is  set 
to  TRUE.  If  a  double  tape  nark  is  written,  than*  the  statue  of 
TAPE_MARKJREAD  is  set  to  TRUE,  and  the  status  of  DOUBLE_TAPE  MARK  is 
set  to  TRUE,  if  an  end-of-tape  (EOT)  reflector  mark  is  encountered, 
the  status  of  END_OF_TAEE  is  set  to  TRUE. 

Parameters: 

TAPE_DRIVE  is  an  open  handle  an  a  tape  drive  file. 

NUMBE3*  is  the  number  of  consecutive  tape  narks  to  be  written 


Exceptions: 

MXE_EKEOR  is  raised  if  the  file  node  of  the  TAPE  DRIVE  is 

m_FHE. 

SEATUS_HRROR  is  raised  if  TAPEJ3RIVE  is  not  open. 

DEVICE_ERRCR  is  raised  if  an  input  or  output  operation  cannot  be 
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ocnpleted  because  of  a  malfunction  of  the  underlying 
system. 

Motes: 

The  status  of  BID  GF_TAPE  remains  TRUE  until  the  EOT  mark  is  passed 
again  in  the  opposite  (reverse)  direction. 


5. 3. 9.8  Initializing  a  tape 

procedure  INITIALIZEJJNLAHELH3(  TAPE_DRIVE:  in  TAr’E_T¥FE)  ; 
Purpose: 

This  procedure  initializes  an  unlabeled  tape  which  is  loaded  an  the 
drive  identified  by  TAPE_DRXVE  and  sets  the  status  of  LABELfD  to 
FALSE. 

If  the  tape  is  not  located  at  the  begiming-of-tape  (BOT)  reflector 
mark,  than  the  tape  is  rewound  to  the  BOT  reflector  mark.  TV© 
adjacent  tape  marks  are  written  following  the  BOT  reflector  mark. 
The  tape  is  stopped  following  the  begirming-af-tape  reflector  mark. 
The  status  of  TAPE_MARK_READ  is  set  to  HUE.  The  status  of 
DCXJB[£_TAra_MARK  is  set  to  TRUE.  The  status  of  ST. ART_QF_TAPE  is  set 
to  FALSE. 

Parameters: 

TAPE_DRIVE  is  an  open  handle  on  a  tape  drive  file. 

Esceptions: 

MODE  H®OR  is  raised  if  the  file  node  of  the  TAPE  DRIVE  is 

UJ_FTLE. 

STATUS >_ERR0R  is  raised  if  TAPEJ3RIVE  is  not  open. 

DEVICEJOWCR  is  raised  if  an  input  or  output  operation  cannot  be 
oanpleted  because  of  a  malfunction  of  the  underlying 

system. 

Motes: 

The  first  file  is  written  imnadiately  following  the 
begirming-of • -tape  reflector  markin  front  of  the  two  tape  narks 
written  at  initialization. 

To  recycle  a  tape,  it  must  be  reinitialized;  initialization  places 
the  logical  end  of  tape  at  the  beginning  of  the  tape. 


tv-. 
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5. 3.9.9  Initializing  a  labeled  tape 

procedure  INITIALIZE  LABELED  (  TAPE_DRIVE:  in  TAPE  TYPE; 

“  VOLUME  ID:  in  \mJME_STRIN3; 

ACCESSIBILITY  :  in  VaJUJE^ACaESS:-"  "); 

Purpose: 

This  procedure  initializes  a  labeled  tape  vfaich  is  loaded  an  the 
drive  identified  by  TAPE_DRTVE.  A  file  header,  two  tape  marks,  an 
end-af-file  label,  and  a  double  tape  nark  are  written.  The  tape  is 
stopped  at  the  beginning-of-tape  reflector  mark. 

The  expiration  date  is  set  to  a  space  followed  by  five  zeroes.  The 
file  name  is  arbitrary.  The  section  ruxtber  is  0001.  The  block 
count  is  000000. 


Parameters: 

TAPEJDRIVE 

WXI*e_ID 

ACCESSIBILITY 


is  an  open  handle  on  a  tape  drive  file. 

is  a  string  identifying  the  volume  name. 

are  the  access  rights  to  the  volixne;  a  space 
indicates  NO  access  control. 


Exceptions: 
MDCE  ERROR 


is  raised  if  the  file  mode  of  the  TAPE_DRTVE  is 
IN  FILE. 


STATUS_ERHOR  is  raised  if  TAPE_DRIVE  is  not  open. 


DEVICE  ERROR 


Notes: 


is  raised  if  an  input  or  output  operation  cannot  be 
aespleted  because  of  a  malfunction  of  the  wderlying 
system. 


Vtien  the  first  file  is  written  an  the  tape,  the  file  header  created 
by  this  procedure  will  be  overwritten. 

To  recycle  a  tape,  it  oust  be  reinitialized;  initialization  places 
the  logical  and  of  tape  at  the  beginning  of  the  tape. 
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Parameters: 

TAPE_DRTVE 

V0UUtC_ID 

ACCESSIBILITY 

Exceptional 

MXE_ERHQR 

IN_FILE. 

STATUS_ERHOR 

DEVICE_ERHC« 

USE  ERROR 


is  an  cpen  handle  on  a  tape  drive  file, 
identifies  the  volute. 

is  a  character  representing  the  access  rights  to  the 
volute. 


is  raised  if  the  file  mode  of  the  TAPE  DRIVE  is 


is  raised  if  TAPE_CRTVE  is  not  cpen. 

is  raised  if  an  input  or  output  operation  cannot  be 
ccnpleted  because  of  a  malfunction  of  the  underlying 
system. 

is  raised  if  tape  on  drive  was  mounted  as  an 
unlabeled  tape. 


5.3.9.11  Creating  a  file  header  label 


procedure  FHJE_HEAEER 


(TAPEJKCVE*  in 

TE3CT~ETLEi  in 

EXPIRATION  DATE:  in 


TMETXPE; 

FILE  TYPE; 

STRING  i-"  99366"); 


Purpose: 

This  procedure  creates  a  file  header,  as  described  in  Table  XI,  for 
the  tape  mounted  on  the  drive  identified  by  TAPEJDRIVE. 
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A  file  identifier  is  a  unique  identifier  generated  by  the  CAIS.  The 
creation  date  is  the  time  the  file  header  label  is  written  an  the 
tape.  The  expiration  date  is  the  date  the  file  nay  be  overwritten. 

Parameters* 

TAPE_DRIVE  is  an  open  handle  on  a  tape  drive  file. 

EXPIRATICN_DAIE  is  a  string  identifying  the  date  the  file  ney  be 
overwritten  (six  characters  ’  YYECD'  where  YY  is 
the  year  and  CCD  is  the  day  (801-366)).  When 
the  expiration  date  is  a  space  followed  by  five 
zeroes,  the  file  has  expired. 

TEXT_FILE  is  the  file  to  be  written  to  tape. 

Exceptions* 

M3CES  ERROR  is  raised  if  the  file  node  of  the  TAPE  DRIVE  is 

IN_FTLE. 

STATUS _QBOR  is” raised  if  TAPE_CRTVE  is  not  open. 

DGVICE_ERR0R  is  raised  if  an  input  or  output  operation  cannot  be 
ooapleted  because  of  a  malfunction  of  the  wderlying 
system. 

USE_ERHOR  is  raised  if  tape  on  drive  wee  mounted  as  an 

unlabeled  tape. 

Notes* 

When  overwriting  a  file,  first  check  the  expiration  date  in  the  file 
header  label.  If  the  existing  fils  has  expired,  then  beck  vp  and 
overwrite  the  old  File-Header  label  with  the  new  File-Header  label. 

If  the  existing  file  has  not  expired,  it  nay  not  be  overwritten. 


5.3.9.12  Creating  an  end  file  label 

procedure  QD_Fnz_IABEL(TAPE_DRIVE*  in  TAPE_TYPE; 

TEXT  FILE*  in  Fn£~TYPE; 

EXPlSvnCNJWIE*  in  STRING  *-  “  99366"); 

Purpoeet 

This  procedure  creates  an  end  file  label,  as  shown  in  Table  XII,  for 
the  tape  mounted  on  the  drive  identified  by  TAPE  DRIVE.  This  label 
is  written  at  the  and  of  a  carpi ete  file. 
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TABLE  XZI.  End  of  File  Label 


Character 

Position 

Field  Name 

Contents 

1  to  3  1 

Label  Identifier 

EOF 

4  1 

Label  Nwfcer 

1 

5  to  54  1 

Sana  as  corresponding 

Same  as  corresponding 

fields  in  HDR1 

fields  in  HDR1 

55  to  60  I 

Block  Count 

NwHbar  of  blocks  in 

file 

61  to  80  I 

Sams  as  corresponding 

Same  as  corresponding 

fields  in  HDR1 

fields  in  HDR1 

The  creation  date,  the  file  identifier,  and  the  expiration  date 
mefadi 


the  aorresponding  fields  in  the  file  header  label. 
Pararaetersi 

TAPE  DRIVE  is  an  open  handle  on  a  tape  drive  file. 


EXPIHATICNJ»TE  is  a  string  identifying  the  date  the  file  nay  be 
~  overwritten  (six  characters  '  YYDDD' ,  where  YY  is 


the 

has 

TEXT |_FHE 

Exceptions! 
HDCE  nw» 


year  and  COO  is  the  day  (001-366).  When  expiration 
date  is  a  space  followed  by  five  zeroes,  the  file 


expired. 

is  the  file  to  be  written  to  tape* 


is  raised  if  the  file  node  of  the  TAPE  DRIVE  is 
IN  PILE. 


9EKKJSJSRRQR  is  raised  if  TAPE_DRIVE  is  not  cpen. 

DEVICEJ3BCR  is  raissd  if  an  iiput-output  operation  cannot  be 

acnplstad  because  of  a  malfunction  of  the  underlying 
systmn. 

USEJ9RR0R  is  raised  if  tape  on  drive  was  mounted  as  an 

unlabeled  tape. 


5.4  CMS  Utilitii 


This  section  defines  the  abstract  data  type  LXSTJKPE. 


5.4.1  Padeags  CAIS_LISrjJnLrnES 

this  package  defines  the  abstract  data  type  LIST  TYPE  far  use  by  other 
CMS  interfaces.  The  value  of  an  entity  of  type  lIsrjKHE  (referred  to 
ae  a  "list")  is  a  linearly  ordered  set  of  data~itens  called  "list 
itmns". 

It  is  possible  to  associate  a  name  with  a  list  item.  If  no  name  is 
associated  with  a  list  item,  the  item  is  an  "ixmsraed"  item.  If  a  name 
is  associated  with  a  list  item,  the  item  is  a  “named"  item.  A  list  oan 
either  oorrtain  all  unnamed  items,  in  Whidi  case  it  is  called  an  unnamed 
list,  or  all  named  items,  in  which  case  it  is  called  a  named  list,  but 
not  both.  If  a  list  contains  all  named  items,  names  among  these  itmas 
must  be  unique.  A  null  list  is  a  list  Which  contains  null  itmas.  Such 
a  list  is  neither  of  a  named  or  unnamed  kind.  A  null  list  can  be 
obtained  by  using  the  HULL  LIST  function  or  OBJSIE  procedure.  The  type 
LIOTJOND  enuneratee  these- three  classifications  of  lists. 

Associated  with  each  list  item  is  a  classification,  or  kind.  List  i 
are  classified  aa  strings,  integer  and  real  ambers,  enuneratian  val 
and  lists.  The  kind  of  an  item  is  a  value  of  the  enumeration 
nfMJOND. 

The  specifications  within  this  package  allow  for  the  lmnlpulat.ic 
lists  which  are  either  of  unnamed  or  named  kind.  If  a  parameter  of 
interface  specifies  an  item  by  position,  than  that  interface  may  be 
with  either  unnamed  lists  or  named  lists.  If,  however,  a  parameter 
specifies  an  item  by  nan,  than  the  associated  interface  nay  only  be 
used  with  named  lists. 

The  value  of  an  entity  of  U9TJHPE  oan  be  externally  represented  as  a 
string.  Interfaces  are  provided~'to  convert  between  entities  of  type 
SC KENS,  containing  a  string  value  consistent  with  the  syntax  of  this 
external  representation,  and  entities  of  type  LISTJHFE. 

The  EKF  for  a  list's  external  representation  is  given  in  Table  Mil. 


Is  a,  $18 


subtype  LIST  TBCT  is  STRING; 
subtype  natbrjOSCT  is  STRING; 
subtype  NWC  3TRING  is  SIRING; 

type  (XUff  is  range  0  ..  inpleraantation  defined; 
siftftype  POSTnONJXUir  is  erwr  range  OOUfT'FI&ST  +1  ..  OCUTT'LAST; 

LISTJCQD  enumerates  the  unnamed  and  named  kinds  of  lists.  ITQIJCXND  enumerates 
the  classifications  of  list  items.  LIST  TBCT  is  the  type  of  a  list's  external 
representation.  ITEM  TEXT  is  the  type  6£  a  list-item's  external  representation. 
NAME  SIRING  is  the  type  of  an  item' a  name  in  a  named  item. 
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SEARCHJBRRCR  i  exception? 


Ttw  exception  SEARCHJSRROR  is  raised  if  a  search  for  a  named  item  fails 
iten's  position  falls  outside  the  range  of  the  list's  length. 


5.4.1. 2  Establishing  a  null-list 
function  NUUj_LXST  return  LISTJKPE; 
Purpose: 

This  function  returns  a  null  list. 

Parameters: 

NOne. 

Exceptions: 

*e - 

wane# 


5.4.1. 3  Converting  from  an  external  list  representation 
function  TCTLIOT  (LIST_LITERALi  in  LZSTJSXT)  return  LZSTjmC; 
Purpose: 

This  function  converts  the  external  representation  of  a  list  to 
LIST  TYPE  and  returns  that  converted  value.  This  function 
eetsElishes  the  list  to  be  of  a  named,  wnnamad  or  null  kind. 
Parameters: 


or  if  an 


LIST_LITERAL 

Exceptions: 

USE  ERROR 


is  the  external  representation  of  the  list. 


is  raised  if  LIST JITBML  dose  not  oonfonn  to 
the  syntax  as  specified  in  Table  XVII. 


5.4. 1.4  Converting  to  external  list  representation 

function  TO_TEXT  (LIST:  in  LISTJTm)  return  LZSTJIEXT; 

procedure  TOJODCT  (LIST:  in  LIST_TYPE; 

LIST  LITERAL:  out  LIST  TBCT; 

LJSTTwn®*  out  natural); 

Purpose: 

This  function/prooedure  oonverte  a  list  to  its  extsrnal 
representation. 


.N  .N  w*.  -*»  .N 
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Parameters: 

LIST  _  is  the  list  to  be  converted. 

LIST_LITERAL  is  the  external  representation  of  LIST. 

LIST- RANGE  is  the  length  of  the  string  returned  in 

LIST  LITERAL. 


Exceptions: 

OCNSrrRAHir_E3®OR  is  raised  if  the  length  of  the  string  resulting 
froa  the  conversion  exceeds  the  size  of 
His1!1  LiitwAL. 


5. 4. 1.5  Inserting  an  item  into  a  list 

LIST  ELEMENT:  in  ELEMOnVEEXT; 
POSITION:  in  aONT; 

IS  STRING:  in  BOOLEAN: -FALSE); 


procedure  INSERT  (LIST  <  in  out  LISTJRRE; 

LIST  ELBCOT:  in  EUMBirjIBCT; 
NAM&:  in  NAM!  SIRING;  ~ 
POSITION:  in  dOUHT; 

IS  STRING:  in  BOOLEAN: -FALSE) ; 


Purpose: 

This  procedure  inserts  an  item  into  a  list  aft ear  the  list  item 
specified  by  POSITION,  a  value  of  zero  MO  in  POSITION  specifies  a 
position  at  the  head  of  the  list.  The  position  order  of  the  items 
in  the  list  following  the  inserted  item  will  assume  new  ordinal 
values  starting  with  the  value  POSITION  +1.  An  insertion  of  a  named 
list  item  into  an  «pty  list  will  determine  that  list  to  be  of  named 
kind  from  than  on.  Conversely,  an  insertion  of  a  unnamed  list  item 
will  determine  that  list  to  be  of  unnamed  kind. 


LIST 

LIST  B0CNT 
NAPED 

POSITION 
IS  SIRING 


is  the  list  into  which  the  item  will  be  inserted. 

is  the  list  item  to  be  inserted. 

is  the  name  of  the  new  item.  It  may  only  be  used 

with  named  lists. 

is  the  position  specification. 

allows  a  list  element  of  STRING_ITEM  kind  to  be 
expressed  as  a  ncn-quotsd  string  if  set  TRUE. 


Exceptions: 

SEAHCH_ERBOR 

USE  ERROR 


is  raised  if  POSITION  specifies  a  value  larger 
than  the  (existing)  length  of  the  list, 
is  raised  if  an  attempt  is  mde  to  insert  a  named 
list  item  into  an  unnamed  list  or  conversely,  an 
attenpt  is  made  to  insert  an  unnamed  list  item 
into  a  named  list. 
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5.4. 1.6  Resetting  the  value  of  a  named  item 

procedure  apsisr  (LIST*  in  out  LIST  TYPE; 

POSITION;  in  P06ITICN- COUNT; 
LISr_ELB>Birt  in  oMMrJkxrh 

procedure  rmwbt  (LIST  t  in  out  LIST  TYPE; 

NAACD  «  in  SMC  STRING; 

LIST  :3L2MQ/r»  in  ELS®Tr_TBCr) ; 

Purpose; 

This  procedure  replaces  an  itrnn  in  the  specified  list.  The  ner  item 
gust  be  of  the  same  itmn  kind  as  that  it  replaces. 

Parameters; 

LIST  is  the  list  containing  the  item  to  be  replaced. 

POSITION  is  the  position  within  the  list  to  identify  the 

item  to  be  replaced. 

NAtCD  is  the  name  of  the  item  to  be  replaced. 

LISTHLEMENT  is  the  new  item. 

Exceptions; 

USE  ERROR  is  raissd  if  LIST_HLMNT  doss  not  replace  a  list 

item  of  the  same  item  kind. 

SEARCH_ERROR  is  raised  if  there  is  no  item  with  the  NAMES 
ocnpcnent  or  if  POSITION  has  a  value  larger  than 
the  (existing)  length  of  the  list. 


5.4. 1.7  Extracting  an  item 

procedure  EXTRACT  (LIST  ;  in  UST  TYPE; 

POSITION;  in  POSfl&CNJXHMT; 

LIST  BSCNTt  out  OQRMT  TEXT; 

mMJttNSE;  out  POSITIVE); 

procedure  EXTRACT  (LIST;  in  LIST  TYPE; 

NAADt  in  NAACSIRING; 

LIST  EUAQfTt  cut  EU9fifT_TEXT; 

rmTRANOE;  out  POSITIVE); 

function  EXTRACT  (LIST  ;  in  LIST  TYPE; 

POSITION  ;  in  roSTTICNJXUTT) 

~  return  ELEMEOT_TTXT; 

function  EXTRACT  (LIST  i  in  LI3T_IYPB; 

NAME  t  in  NAME~STRING)  return  ELEMBCT_TEXr; 

Purpose; 

This  procedure  returns  the  list  item  in  LIST  ELEMENT  as  specified  by 
P06OTCN  or  NAACD  without  removing  the  item  Iraa  the  list. 
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The  function  counterparts  sinply  return  the  list  item. 
Parameter*! 


LIST 

position 

MAMS) 

LIST  QL0CNT 
ITEM- RANGE 


is  the  list  containing  the  item. 

is  the  position  within  the  list  that  identifies 

the  item  to  be  extracted. 

is  the  name  of  the  item  to  be  extracted. 

is  the  itan  read. 

is  the  length  of  the  string  returned  in 
LIST  EUMMT. 


Exceptional 

USEJQWOR  is  raised  if  LIST  is  anpty. 

CONSTRAINT  ERROR  is  raised  if  the  length  of  the  string  in  the 
returned  item  exceeds  the  size  of  LIST_0£>CNT. 
SEARCH_ERS0R  is  raised  if  there  is  no  item  with  the  MAMS) 

”  component  or  if  POSITION  has  a  value  larger  than 

the  (existing)  length  of  the  LIST. 


5.4. 1.8  Deleting  an  item  from  a  list 


procedure  EOJETE 

(LIST  ! 

in 

out  LIST  TYPE? 

POSITION! 

in 

posrnoN_oooNr )  ? 

procedure  OELEME 

(LIST: 

in 

OUt  LIST  TYPE; 

MAMEDi 

in 

NAM!  STRING); 

Purpose: 


This  procedure  deletes  the  list  item  specified  by  POSITION  or  MAMED 
from  LIST. 


Parameters! 

LIST  is  the  list  from  which  the  item  will  be  deleted. 

POSITION  is  the  position  within  the  list  that  identifies 

the  itmn  to  be  deleted. 

NAtO  is  the  name  of  the  list  item  to  be  deleted. 


Exceptions! 

SEARCH  ERROR  is  raised  if  there  is  no  item  with  the  MAMED 
oaapcnent  or  if  POSITION  has  a  value  larger  than 
the  (existing)  length  of  LIST. 

is  raised  if  the  parameter  MAMED  is  used  with  an 
interned  list. 


USE  ERROR 
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5. 4. 1.9  Determining  the  kind  of  list  or  the  kind  of  list  item 

function  KIND  (LIST  :  in  LI£7T_TYPE)  return  LISTJdND? 

function  KUO  (LIST:  in  LIST  TYPE; 

POSITION:  in  %6mCM_0CUir)  return  nOMOa©; 


function  KIND  (LIST:  in  LIf7T_T5fPEj 

NAMED:  in  NAFE  STRING)  return  ITB4  KUO; 


Purpose: 


This  function  returns  either  the  kind  of  list  or  the  kind  of  item  in 
the  referenced  list. 

Parameters: 


LI ST  is  the  list  of  interest. 

POSITION  is  the  position  within  the  list  that  identifies 

the  item. 

NAMED  is  the  name  of  the  list  itan. 

Exceptions: 

SEARCH_ERROR  is  raised  if  there  is  no  item  with  the  NAMED 
oanponent  or  if  POSITION  has  a  value  larger  than 
the  (existing)  length  of  LIST. 


5.4.1.10  Merging  two  lists 

procedure  MERGE  (FRONT  :  in  LIST  TYPE; 

BACK  :  in  LIST" THE; 

RESULT  :  in  out  USTJTYPE); 

Purpose: 

This  procedure  returns  in  RESULT  a  list  constructed  from  the  lists 
FRONT  and  BACK.  The  lists  FRONT  and  BACK  must  be  of  the  same  kind. 

Parameters: 

FRONT  is  the  first  list  to  be  merged. 

BACK  is  the  second  list  to  be  merged. 

RESILT  is  the  list  produced  by  the  merge. 

Exceptions: 

USEJERROR  is  raised  if  FRONT  and  BACK  are  not  of  the  same 

kind. 
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5.4.1.11  Determining  the  length  of  the  list 

function  LENGTH  (LIST  :  in  LIST  TYPE)  return  (DUNT; 


Purposes 

This  function  returns  a  count  of  the  ranfcer  of  items  in  LIST.  If 
LIST  is  enpty,  LQJGIH  returns  zero. 

Parameters  i 

LIST  is  the  list  of  interest. 

Exceptions! 

None. 


5.4.1.12  Determining  the  nans  of  a  named  item 


procedure  ITEM  KMC  (LIST  s  in  LIST  TYPE 

”  POSITIONS  in  POSITION  COUNT; 
mtOs  out  NAtC  STRING; 

KMC  RANGES  out  POSITIVE); 


function  ITEMJMC  (LIST  s 

POSITION 


Purposes 


in  LIST  TYPE; 
in  POSITION  COUNT) 

~  return  NAME  STRING; 


This  procedure/fwction  returns  the  name  of  the  list  item  in  a  named 
list,  opacified  by  POSITICN. 


LIST 

POSITION 

mm 

NAtC  RANGE 


is  the  list  of  interest. 

is  tin  position  within  the  list  that  identifies 
the  item. 

is  the  string  representation  of  the  list  item  name, 
is  the  length  of  the  string  returned  in  NAMB3. 


Exceptions: 

SEARCH_ERROR  is  raised  if  POSITICN  has  a  value  larger  than  the 
(existing)  length  of  LIST. 

USE  ERROR  is  raised  if  LI ST  is  not  a  named  list. 
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5.4.1.13  Determining  the  length  of  a  string  representing  a  list  or  a 
list  item 

function  TEXTLQOIH  (LIST:  in  LISTTYPB)  return  NPOTRAL; 

function  TEXT  LENGTH  (LIST:  in  LIST  TYPE; 

POSITION:  in  POSITION  COUNT) 

~  return  POSITIVE; 

Purpose; 

This  function  returns  the  length  of  a  string  representing  either  a 
list  or  the  list  item  identified  by  POSITION  in  a  list. 

Parameters; 

LIST  is  the  list  of  interest. 

POSITION  is  the  position  within  the  list  that  identifies  the 
item. 

Exceptions: 

SEARCH_HWOR  is  raised  if  POSITION  has  a  value  larger  than  the 
“  (existing)  length  of  LIST. 
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APPQDIX  A 


Predefined 
Relation  Manes 


Relations 
and  Attributes 


Predefined  Relations: 

ACCESS 
ADOPTED JCLE 
ASSOCIATE 
CURRmr  BOOR 
CUBROnTlMEVr 
CURRENT  JOB 
CURHENT_NCCE 
CURRENT  OUTPUT 
CURRENT JJSER 
DEVICE  ~ 

JOB 

ROLE 

PARENT 

PERMANENT J€*«ER 
POTENTIAL  WWSl 

standardJBbvt 

STANDARD  OUHVT 

SEANDARD_n®OR 

USER 


Predefined  Attributes: 

AOCESS_MEIHOD 
CURRENT  STATUS 
PHEJCM) 

ETNISH_TTMS 

GRANT 

HANDLES  OPEN 
HIGHEST- CLASS  UTCAITCN 
10  INTIS' 

LOWEST  CLASSIFICATION 
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OBJECT  CLASSIFICATION 

PARAMETER__LIST 

QUEUE  TYPE 

RESULTS  LIST 

SIZE 

START  TBC 

SUBJECT  CLASSIFICATION 
TERMINAL  TYPE 


Predefined  Attribute  values t 

CONTROL 

CDPY 

DIRECT 

EXECUTE 

EXISTENCE 

FORM 

MAGNETIC  TAPE 
MIMIC  ” 

PAGE 

QUEUE 

READ 

READJOTRIBUTES 
READjXNITNTS 
READ  RELATIONSHIPS 
SCRCfl 

SEOONDARY_STORAG£ 

SEQUENTIAL 

SOLO 

TERMINAL 

TEXT 

WRITE 

WRITE ^ATTRIBUTES 
WRITE  OQNTENIS 
WRITE  RELATIONSHIPS 
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APPE2DZX  B 
CMS  SPECIFICATION 


This  appendix  contains  a  set  of  Ada  package  spdfications  of  the  CMS 
interfaces  which  compiles  correctly.  It  brings  togethr  most  of  the 
interfaces  found  in  Section  5  using  the  Masted  Generic  Subpackages 
Inplenentation  approach.  Althcu^i  the  interfaces  are  not  necessarily 
shown  hers  in  the  order  in  vrtiich  they  are  discussed  in  the  text,  this 
appendix  provides  a  reference  listing  of  the  CMS  as  wall  as  an 
illustration  of  the  generics  approach. 
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PREFACE 

The  KAPSE  Interface  Team  (KIT),  and  its  companion  Industry-Academia  team  (KIT1A),  were  formed  by 
a  Memorandum  of  Agreement  (MOA)  signed  by  the  three  serf  ices  and  the  Undersecretary  of  Defense  in 
January,  1982.  Their  purpose  is  to  contribute  to  the  achievement  of  Interoperability  of  applications 
databases  and  Transportability  of  software  development  tools  (MAT*).  These  arc  important  economic 
objectives,  identified  at  the  outset  of  the  DoD  common  language  initiative  in  the  mid* 1970's  and  now 
acknowledged  to  require  an  integrated  Ada  Programming  Support  Environment  (APSE),  in  addition  to  the 
staodard  language  Ada,  for  fulfillment.  The  eore  of  the  KIT/KITIA  strategy  to  fulfill  IfcT  objectives  is  to 
define  a  standard  set  of  Ada  Programming  Support  Environment  (APSE)  interfaces  (‘CAIS*  for 
■Common  APSE  Interface  Set*)  to  which  all  Ada*related  tools  can  be  written,  thus  assuring  the  ability  to 
share  tools  and  databases  between  conforming  Ada  Programming  Support  Environments  (APSEs).  Note 
that  a  large  number  af  these  interfaces  are  at  the  Kernel  APSE  (KAPSE)  level.  This  document  establishes 
requirements  and  design  objectives  (called  'criteria*)  on  the  definition  of  a  CAIS. 

This  document  is  related  to  the  DoD  ■Sfconem.’ia*  Requirements  for  Ads  Programming  Support 
Environments  in  identifying  and  refining  the  derived  requirements  which  are  imposed  upon  a  CAIS  and 
which  effect  the  I&T-related  objectives.  Additional  influences  on  this  document  were  the  DoD  'Steelman* 
Requirements  for  High  Order  Computer  Programming  Languages  and  the  several  sets  of  ANSI  *OSCRL* 
requirements  and  design  objectives  for  Operating  System  Command  and  Response  Languages. 
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1.  INTRODUCTION 


1.1  Scopw.  This  document  provides  the  Department  of  Defense's  requirements  and  design  criteria  for 
the  definition  and  specification  of  a  Common  APSE  Interface  Set  (CAIS)  for  Ada  Programming  Support 
Environments  (APSEs). 


1.1  Terminology.  The  precise  and  consistent  nse  of  terms  has  been  attempted  throughout  the 
document. 

Many  potentially  ambiguous  terms  have  been  used  in  the  document.  Mont  are  defined  in  the  Glossary  of 
KIT/KITIA  terminology.  Some  are  defined  in  the  sections  where  they  are  used  with  definitions  tailored  to 
the  context  of  this  document. 

Additionally,  the  following  verbs  and  verb  phrases  have  been  need  consistently  throughout  the  document 
to  indicate  where  and  to  what  degree  individual  constraints  apply.  Any  sentence  not  containing  one  of  the 
following  verbs  or  verb  phrases  is  a  definition,  explanation  or  comment. 

■shall*  indicates  a  requireaent  on  the  definition 

of  the  CAIS;  soaetiaes  •shall*  is  folloeed 
by  ‘provide*  or  'support,*  in  which  cases 
the  following  two  definitions  supercede 
this  one. 

■shall  provide*  indicates  a  requireaent  for  the  CAIS  to 

provide  interface (s)  with  prescribed 

capabilities. 

*shall  support*  Indicates  a  requireaent  for  the  CAIS  to 

provide  interface (s)  with  prescribed 
capabilities  or  for  CAIS  definers  to 
denonstrate  that  the  capability  nay  be 
constructed  froa  CAIS  Interfaces. 

'should*  indicates  a  desired  goal  but  one  for  which 

there  is  no  objective  test. 


1.3  Relationship  to  CAIS  Specifications  and  Implementations.  This  document  specifies 
functional  capabilities  which  are  to  be  provided  in  the  semantics  of  a  CAIS  specification  and  are  therefore 
to  be  provided  by  conforming  CAIS  implementations.  In  general,  the  specifications  of  software  fulfilling 
those  capabilities  (and  decisions  about  including  or  not  including  CAIS  interfaces  for  certaio  capabilities  as 
suggested  by  the  'shall  support*  definition  in  the  previous  section)  are  delegated  to  the  CAIS  definers  If 
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a  particular  facility  specified  ia  the  CAIS  it  independent  of  other  CAIS  faeiiitiee,  thea  a  CAIS  implementor 
may  elect  to  rente  CAIS  facilities  to  provide  the  particular  specified  facility,  thereby  achieving  a  'layered 
implementation*  of  the  CAIS.  Therefore,  the  realisation  of  a  specific  CAIS  implementation  it  the  result  of 
iateatioaally  divided  decision-making  authority  among  1)  this  requirements  document,  2)  CAIS  d e finer* , 
aad  31  CAIS  implementors. 
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2.  GENERAL  DESIGN  OBJECTIVES 

2.1  Scop*  of  the  CAIS.  Tbe  CAIS  sbnli  consist  of  the  interfaces  necetnnr)'  mad  sufficient  to  support 
the  use  of  APSEs  throughout  the  lifecycle,  sod  to  promote  I&T  among  APSE*.  The  CAIS  should  be 
broad  enough  to  support  wide  sets  of  tools  and  classes  of  projects.  The  CAIS  is  not  required  to  provide  all 
general  operating  system  capabilities. 


2.2  Basic  Services.  The  CAIS  should  provide  simple-to-use  mechanisms  for  achieving  common,  simple 
actions.  Features  which  support  less  frequently  used  tool  needs  should  be  given  secondary  consideration. 


2.3  Implementablllty.  The  CAIS  specification  shall  be  machine  independent  and  implementation 
independent.  The  CAIS  shall  be  implementable  on  bare  machines  and  on  machines  with  any  of  a  variety 
of  operating  systems.  The  CAIS  shall  contain  only  interfaces  which  provide  facilities  which  have  been 
demonstrated  in  existing  operating  systems,  kernels,  or  command  processors.  CAIS  features  should  be 
chosen  to  have  a  simple  and  efficient  implementation  in  many  object  machines,  to  avoid  execution  costs 
for  unneeded  generality,  and  to  ensure  that  unused  portions  of  a  CAIS  implementation  will  not  add  to 
execution  costs  of  a  non-using  tool.  The  measures  of  the  efficiency  criterion  are.  primarily,  minimum 
interactive  response  time  for  APSE  tools  and.  secondarily,  consumption  of  tool-chargeable  resources 


2.4  Modularity.  Interfaces  should  be  designed  in  a  modular  fashion  such  that  they  may  be  understood 
in  isolation  and  such  that  there  are  no  bidden  interactions  between  interfaces.  This  permits  a  tool  writer 
to  employ  a  subset  of  the  CAIS. 


2.5  Extensibility.  Tbe  design  of  tbe  CAIS  should  facilitate  development  and  use  of  portable 
extensions  of  the  CAIS:  i.e..  CAIS  interfaces  should  be  reusable  so  that  they  can  be  combined  to  create 
new  interfaces  and  facilities  which  are  also  portable. 


2.6  Technology  Compatibility.  Tbe  CAIS  shall  adopt  existing  standards  where  applicable.  For 
example,  recognized  standards  for  device  characteristics  are  provided  by  ANSI,  ISO,  IEEE,  and  DoD. 


2-1 
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1.7  Consistency •  The  design  of  tbe  CAIS  should  minimise  the  number  of  underlying  concepts.  It 
should  have  few  special  cases  and  should  consist  of  features  that  are  individually  simple.  These  objective* 
are  not  to  be  pursued  to  the  extreme  of  providing  inconvenient  mechanisms  for  the  expression  of  some 
common,  reasonable  actions. 

S.S  Security.  Tbe  CAIS  shall  be  implementable  as  a  secure  system  that  fulfills  the  requirements  for  a 
Class  (B2)  system  in  the  DoD  document  titled  'Trusted  Computer  System  Evaluation  Criteria.*  The 
CAIS  shall  be  designed  to  mediate  all  tool  access  to  underlying  system  services  (i.e..  no  'by-passing*  the 
conforming  CAIS  implementation  is  necessary  to  implement  any  APSE  function).  The  CAIS  should 
accommodate  implementations  that  coexist  with  (without  compromising)  and  operate  within  a  variety  of 
security  mechanisms. 
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3.  GENERAL  SYNTAX  AND  SEMANTICS 

1.1  Syntax 

9.1A  General  Syntax.  The  syntax  of  the  CAIS  shall  be  expressed  as  Ada  package  specifications. 
The  syntax  of  the  CAIS  shall  conform  to  the  character  set  as  defined  by  the  Ada  standard  (section  2.1  of 
ANSI/MIL-STD-1815A). 

3.1B  Uniformity.  The  CAIS  should  employ  uniform  syntactic  conventions  and  should  not  provide 
several  notations  for  the  same  concept.  CAIS  syntax  issues  (including,  at  least,  limits  on  name  lengths, 
abbreviation  styles,  other  naming  conventions,  relative  ordering  of  input  and  output  parameters,  etc.) 
should  be  resolved  in  a  uniform  and  integrated  manner  for  the  whole  CAIS. 

3. 1C  Nome  Selection.  The  CAIS  should  avoid  coining  new  words  (literals  or  identifiers)  and  should 
avoid  using  words  in  an  unconventional  tense.  Ada  identifiers  (names)  defined  by  the  CAIS  should  be 
natural  language  words  or  industry  accepted  terms  whenever  possible.  The  CAIS  should  define  Ada 
identifiers  which  are  visually  distinct  and  not  easily  confused  (including,  at  least,  that  the  CAIS  should 
avoid  defining  two  Ada  identifiers  that  are  only  a  2-character  transposition  away  from  being  identical) 
The  CAIS  should  use  the  same  name  everywhere  is  the  interface  set,  and  not  its  possible  synonyms,  when 
the  same  meaning  is  intended. 

3. ID  Pragmatics.  The  CAIS  should  impose  only  those  restrictive  rules,  constraints,  or  anomalies 
required  to  achieve  IAT.  The  CAIS  specification  shall  enumerate  all  instances  of  syntactic  constraint 
setting  which  are  deferred  to  the  implementor.  CAIS  implementors  will  be  required  to  provide  the 
complete  specifications  of  all  syntactic  restrictions  imposed  by  their  CAIS  implementations. 

3.9  Semantics 

3.3 A  General  Semantics.  The  CAIS  shall  be  completely  and  unambiguously  defined.  The 
specification  of  semantics  should  be  both  precise  and  understandable.  The  semantic  specification  of  each 
CAIS  interface  shall  include  precise  statement  of  assumption  (including  execution-time  preconditions  for 
calis)s.  effects  on  global  data  and  packages,  and  interactions  with  other  interfaces. 
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I.JB  Responses.  The  CAIS  shall  provide  standard  responses  for  all  interfaces,  including  a  unique, 
non-null  response  (return  value  or  exception)  for  each  type  of  unsuccessful  completion.  All  responses 
returned  across  CAIS  interfaces  shall  be  defined  in  an  implementation-independent  manner.  Everytime  a 
CAIS  interfaces  is  called  under  the  same  circumstances,  it  should  return  the  same  response. 

3.SC  Exceptions.  All  named  exceptions  raised  and  propagated  by  the  CAIS  shall  be  documented. 
The  CAIS  specification  shall  require  CAIS  implementations  to  provide  handlers  for  all  unnamed  exceptions 
raised  in  the  implementations'  bodies. 

3.3D  Consistency.  The  description  of  CAIS  semantics  should  use  the  same  word  or  phrase 
everywhere,  and  not  its  possible  synonyms,  when  the  same  meaning  is  intended. 

3.3E  Coheslveneae.  Each  CAIS  interface  should  provide  only  one  function. 

3.3F  Pragmatics.  The  CAIS  specification  shall  enumerate  all  aspects  of  the  meanings  of  CAIS 
interfaces  and  facilities  which  must  be  defined  by  CAIS  implementors.  CAIS  implementors  will  be 
required  to  provide  the  complete  specifications  for  these  implementation-defined  semantics. 
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4.  ENTITY  MANAGEMENT  SUPPORT 


This  characterization  of  Entity  Management  Support  is  based  on  the  STONEMAN  requirements  for  a 
database,  using  a  model  based  on  the  entity-relationship  concept.  Although  a  CAIS  design  meeting  these 
requirements  is  expected  to  demonstrate  the  characteristics  and  capabilities  reflected  here,  it  is  not 
necessary  that  such  a  design  directly  employ  this  entity-relationship  model. 

The  general  capabilities  required  in  the  model  specified  by  the  CAIS  are  the  following.  The  entity, 
relationship  model,  for  which  definitions  and  requirements  follow  in  4.1  -  4.?  provides  these  capabilities, 
and  any  alternative  model  of  CAIS  requirements  must  also. 

a.  There  must  be  a  means  for  retaining  data. 

b.  There  must  be  a  way  for  retaining  relationships  and  properties  of  data. 

c.  There  must  be  a  way  of  operating  upon  data  and  creating  new  data  (and  deleting  data). 

d.  There  must  be  a  means  to  determine  whether  the  properties  of  an  item  of  data  are  valid  and 
whether  operations  upon  it  are  valid. 

e.  There  must  be  a  way  to  restrict  operations  on  as  item  of  data  to  valid  ones. 

f.  There  must  be  a  description  of  each  item  of  data  and  that  descriptioa  may  be  operated  upon. 

g.  The  relationships  and  properties  of  data  must  be  separate  from  their  existence  and  separate 
from  the  tools  that  operate  upon  them. 

b.  There  must  be  a  way  to  develop  new  data  by  inheriting  (some  of)  the  properties  of  existing 


4.1  Entitles,  Relationships,  and  Attributes  The  following  definitions  pertain  specifically  to  this 


ENTITY 


A  representation  of  a  person,  place,  event  or  thing. 


RELATIONSHIP  An  ordered  connection  or  association  among  entities.  A  relationship  among  N  entities 
(not  necessarily  distinct)  is  known  as  an  *N-ary*  relationship. 

ATTRIBUTE  An  association  of  an  entity  or  relationship  with  an  elementary  value 


3-261 


i 

,  «» 
L> 

S 


DoD  CAIS  Requirements  &  Design  Criteria 


Ifl  October  1984 


ELEMENTARY  VALUE 

Oae  of  two  kinds  of  representations  of  data:  interpreted  and  ■■interpreted 
INTERPRETED  DATA 

A  data  representation  whose  structure  is  controlled  by  CAIS  facilities  and  may  be  used 
in  the  CAIS  operations.  Examples  are  representations  of  integer,  string,  real,  data  and 
enumeration  data,  and  aggregates  of  suck  data. 

UNINTERPRETED  DATA 

A  data  representation  whose  structure  is  not  controlled  by  CAIS  facilities  and  is  not 
used  in  the  CAIS  operations.  Examples  might  be  representations  of  Hies,  such  as 
requirements  documents,  program  source  code,  and  program  object  code. 
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4.1A  Data.  The  CAIS  shall  provide  facilities  for  representing  data  using  entities,  attributes  or  binary 
relationships.  The  CAIS  may  provide  facilities  for  more  general  N-ary  relationships,  but  it  is  not  required 

to  do  so.  ^ 

& 

4.1B  Elementary  Values.  The  CAIS  shall  provide  facilities  for  representing  data  as  elementary 

values.  £•*, 

t*'. 

4.1C  System  Integrity.  The  CAIS  facilities  shall  ensure  the  integrity  of  the  CAIS-managed  data. 


4.S  Typing  The  following  definition  pertains  specifically  to  this  section: 

TYPING  An  organisation  of  entities,  relationships  and  attributes  is  which  they  are  partitioned 

into  sets,  called  entity  types,  relationship  types  and  attribute  types,  according  to 
designated  type  definitions. 

4.2A  Types.  The  facilities  provided  by  the  CAIS  shall  enforce  typing  by  providing  that  all  operations 
conform  to  the  type  definitions.  Every  entity,  relationship  and  attribute  shall  have  one  and  only  one  type. 


b 


4.2B  Rules  about  Type  Definitions.  The  CAIS  type  definitions  shall 

e  specify  the  entity  types  and  relationship  types  to  which  each  attribute  type  may  apply 

s  specify  the  type  or  types  of  entities  that  each  relationship  type  may  connect  and  the  attribute 
types  allowed  for  each  relationship  type 

e  specify  the  set  of  allowable  elementary  values  for  each  attribute  type 

e  specify  the  relationship  types  and  attribute  types  for  each  entity  type 

e  permit  relationship  types  that  represent  either  functional  mappings  (one-to-one  or  many-to- 
oae)  or  relational  mappings  (one- tommy  or  many-to-masy ) 
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•  permit  multiple  distinct  relationships  among  the  same  entities 

*  impose  a  lattice  structure  on  the  types  which  includes  inheritance  of  attributes,  attribute  value 
ranges  (possibly  restricted),  relationships  and  allowed  operations. 

4.3C  Typo  Definition.  The  CAIS  shall  provide  facilities  for  defining  new  entity,  relationship  and 
attribute  types. 

4.3D  Changing  Type  Definitions.  The  CAIS  shall  provide  facilities  for  changing  type  definitions. 
These  facilities  shall  be  controlled  such  that  data  integrity  is  maintained. 

4.2E  Triggering.  The  CAIS  shall  provide  a  conditional  triggering  mechanism  so  that  prespecified 
procedures  or  operations  (such  as  special  validation  techniques  employing  multiple  attribute  value 
checking)  may  be  invoked  whenever  values  of  indicated  attributes  change.  The  CAIS  shall  provide 
facilities  for  defining  such  triggers  and  the  operations  or  procedures  which  are  to  be  invoked. 


4.3  Identification  The  following  definitions  pertain  specifically  to  this  section: 

EXACT  IDENTITY 

A  designation  of  an  entity  (or  relationship)  that  is  always  associated  with  the  entity  (or 
relationship)  that  it  designates.  This  exact  identity  will  always  designate  exactly  the 
same  entity  (or  relationship),  and  it  cannot  be  changed. 

IDENTIFICATION 

A  means  of  specifying  the  entities,  relationships  and  attributes  to  be  operated  on  by  a 
designated  operation. 

4.3A  Exact  Identities.  The  CAIS  shall  provide  exact  identities  for  all  entities.  The  CAIS  shall 
support  exact  identities  for  all  relationships.  The  exact  identify  shall  be  unique  within  an  instance  of  a 
CAIS  implementation,  and  the  CAIS  shall  support  a  mechanism  for  the  utilization  of  exact  identities 
across  all  CAIS  implementations. 


4.3B  Identification.  The  CAIS  shall  provide  identification  of  all  entities,  attributes  and  relationships 
The  CAIS  shall  provide  identification  of  all  entities  by  their  exact  identify  The  CAIS  shall  support 
identification  of  all  relationships  by  their  exact  identity. 
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4.3C  Identification  Methods.  The  CAIS  shall  provide  ideatificatioa  of  entities  and  relationships  by 
at  least  the  following  methods: 

e  identification  of  some  'start'  entity(s),  the  specification  of  tome  relationship  type  and  the 
specification  of  some  predicate  involving  attribute*  or  attribute  type*  associated  with  that 
relationship  type  or  with  some  entity  type.  This  method  shall  identify  those  entities  which  are 
related  to  the  identified  start  entity(s)  by  relationship*  of  the  given  relationships  type  and  for 
which  the  predicate  ia  true.  Subject  to  the  security  constraints  of  section  2.8,  all  relationships 
and  entities  shall  be  capable  of  identification  via  this  method,  and  all  attributes  and  attribute 
types  (except  uninterpreted  data)  shall  be  permitted  ia  the  predicates. 

#  identification  of  an  entity  type  or  relationship  type  and  specification  of  some  predicate  on  the 
value  of  any  attribute  of  the  entity  type  or  relationship  type.  This  method  shall  identify  those 
entities  or  relationships  of  the  given  type  for  which  the  predicate  is  true.  Subject  to  the 
security  constraints  of  section  2.8,  all  attributes  (except  uninterpreted  data)  shall  be  permitted 
ia  the  predicates. 


4.4  Operations 

4.4A  Entity  Operations.  The  CAIS  shall  provide  facilities  to: 

#  create  entities 

e  delete  entities 

#  examine  entities  (by  examining  their  attributes  and  relationships) 

#  modify  entities  (by  modifying  their  attributes) 

#  identify  entities  (as  specified  ia  Section  4.3) 

4.4B  Relationship  Operations.  The  CAIS  shall  provide  facilities  to: 

#  create  relationships 

#  delete  relationships 

#  examine  relationships  (by  examining  their  attributes) 
e  modify  relationships  (by  modifying  their  attributes) 
e  identify  relationships  (as  specified  ia  Section  4.3) 

4.4C  Attribute  Operations.  The  CAIS  shall  provide  facilities  to: 
e  examine  attributes 


*  modify  attributes 
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4.4D  Exact  Identify  Operations.  The  CAIS  shall  provide  facilities  to: 
e  pass  exact  identities  between  processes 

e  compare  exact  identities 

4.4E  Uninterpreted  Data  Operations.  The  CAIS  shall  provide  that  use  of  the  input-output 
facilities  of  the  Ada  language  (as  defined  in  Chapter  14  of  ANSI/MIL-STD-1815A)  results  in 
reading/writing  an  uninterpreted  data  attribute  of  an  entity.  The  facilities  of  Section  8  shall  then  apply. 

4.4F  Synchronisation.  The  CAIS  shall  provide  dynamic  access  synchronisation  mechanisms  to 
individual  entities,  relationships  and  attributes. 

4.5  Transaction.  The  following  definition  pertains  specifically  to  this  section: 

TRANSACTION  A  grouping  of  operations,  including  a  designated  sequence  of  operations,  which  requires 
that  either  all  of  the  designated  operations  are  applied  or  none  are;  e.g..  a  transaction  is 
uninterruptible  from  the  user's  point  of  view. 

4.SA  Transaction  Mechanism.  The  CAIS  shall  support  a  transaction  mechanism.  The  effect  of 
running  transactions  concurrently  shall  be  as  if  the  concurrent  transactions  were  run  serially 

4.5B  Transaction  Control.  The  CAIS  shall  support  facilities  to  start,  end  and  abort  transactions 
When  a  transaction  is  aborted,  all  effects  of  the  designated  sequence  of  operations  shall  be  as  if  the 
sequence  was  never  started. 

4.SC  System  Failure.  System  failure  while  a  transaction  is  in  progress  shall  cause  the  effects  of  the 
designated  sequence  of  operations  to  be  as  if  the  sequence  was  never  started. 

4.6  History.  The  following  definition  pertains  specifically  to  this  section: 

HISTORY  A  recording  of  the  manner  in  which  entities,  relationships  and  attribute  values  were 

produced  and  of  all  information  which  was  relevant  in  the  production  of  those  entities 
relationships  or  attribute  values. 

4.9A  History  Mechanism.  The  CAIS  shall  support  a  mechanism  for  collecting  and  utilizing  history 
The  history  mechanism  shall  provide  sufficient  information  to  support  comprehensive  configuration 
control 
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4. SB  History  Integrity.  The  CA1S  shall  support  mechanisms  for  ensuring  the  fidelity  of  the  history 


4.7  Robustness  and  Restoration.  The  following  definitions  pertain  specifically  to  this  section: 

BACKIT  A  redundant  copy  of  some  subset  of  the  CAIS-managed  data.  The  subset  is  capable  of 

restoration  to  active  use  by  a  CAIS  implementation,  particularly  in  the  event  of  a  loss 
of  completeness  or  integrity  in  the  data  in  use  by  implementation. 

ARCHIVE  A  subset  of  the  CAIS-managed  data  that  has  been  relegated  to  backing  storage  media 

while  retaining  the  integrity,  consistency  and  availability  of  all  information  in  tbe  entity 
management  system. 


4.7A  Rcbustness  and  Restoration.  The  CAIS  shall  support  facilities  which  ensure  the  robustness  of 
and  ability  to  restore  CAIS-managed  data.  The  facilities  shall  include  at  least  those  required  to  support 
tbe  backup  and  archiving  capabilities  provided  by  modern  operating  systems. 
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5.  PROGRAM  EXECUTION  FACILITIES 


Access  controls  and  security  rights  will  apply  to  all  CAIS  facilities  required  by  this  section. 

The  following  definitions  pertain  specifically  to  this  section: 

PROCESS  The  CAIS  facility  used  to  represent  the  execution  of  any  program. 

PROGRAM  A  set  of  compilation  units,  one  of  which  is  a  subprogram  called  the  'main  program  * 

Execution  of  the  program  consists  of  execution  of  the  main  program,  which  may  invoke 
subprograms  declared  in  the  compilation  units  of  the  program. 

RESOURCE  Any  capacity  which  must  be  scheduled,  assigned,  or  controlled  by  the  operating  system 
to  assure  consistent  and  non-conflicting  usage  by  programs  under  execution.  Examples 
of  resources  include:  CPU  time,  memory  space  (actuals  and  virtual),  and  shared 
facilities  (variables,  devices,  spoolers,  etc.). 

ACTIVATE  To  create  a  CAIS  process.  The  activation  of  a  program  binds  that  program  to  its 
execution  environment,  which  are  the  resources  required  to  support  the  process  s 
execution,  and  includes  the  program  to  be  executed.  The  activation  of  a  process  marks 
the  earliest  point  in  time  which  that  process  can  be  referenced  as  an  entity  within  the 
CAIS  environment. 

TERMINATE  To  stop  the  execution  of  a  process  such  that  it  cannot  be  resumed 

DEACTIV  ATE  To  remove  a  terminated  process  so  that  it  may  no  longer  be  referenced  within  the  CAIS 

environment 

SUSPEND  To  stop  the  execution  of  a  process  such  that  it  can  resumed.  In  the  context  of  an  Ada 

program  being  executed,  this  implies  the  suspension  of  all  tasks,  and  the  prevention  of 
the  activation  of  any  task  until  the  process  is  resumed.  It  specifically  does  not  imply 
the  release  of  any  resources  which  a  process  has  assigned  to  it.  or  which  it  has  acquired, 
to  support  its  execution. 

RESUME  To  resume  the  execution  of  a  suspended  process. 

TASK  Wait  The  execution  of  a  task  within  a  process  is  delayed  until  a  CAIS  service  requested  by 
this  task  h3S  been  performed.  Other  tasks  in  the  same  process  are  not  delayed 


S.l  Activation  of  Profram 
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S.1A  Activation.  The  CA1S  shall  provide  a  facility  for  a  process  to  create  a  process  for  a  program 
that  has  been  made  ready  for  execution.  This  event  is  called  activation. 

S.lB  Unambiguous  Identification.  The  CAIS  shall  provide  facilities  for  the  unambiguous 
identification  of  a  process  at  any  time  between  its  activation  and  deactivation;  one  such  capability  shall  be 
as  an  indivisible  part  of  activation.  This  act  of  identification  establishes  a  reference  to  that  process  Once 
such  a  reference  is  established,  that  reference  will  refer  to  the  same  process  until  the  reference  is  dissolved 
A  reference  is  always  dissolved  upon  termination  of  the  process  that  established  the  reference  A 
terminated  process  may  not  oe  deactivated  while  there  are  references  to  that  process 

S.1C  Activation  Data.  The  CAIS  shall  provide  a  facility  to  make  data  available  to  a  program  upon 
its  activation. 

5.1D  Dependent  Activation.  The  CAIS  shall  provide  a  facility  for  the  activation  of  programs  that 
depend  upon  the  activating  process  for  their  existence. 

S.lE  Independent  Activation.  The  CAIS  shall  provide  a  facility  for  the  activation  of  programs  that 
do  not  depend  upon  the  activating  process  for  their  existence. 

6.2  Termination 

S.2A  Termination.  The  CAIS  shall  provide  a  facility  for  a  process  to  terminate  a  process  There 
shall  be  two  forms  of  termination;  the  voluntary  termination  of  a  process  (termed  completion)  and  the 
abnormal  termination  of  a  process.  Completion  of  a  process  is  always  self-determined,  whereas  abnormal 
termination  may  be  initiated  by  other  processes. 

S.2B  Termination  of  Dependent  Processes.  The  CAIS  shall  support  clear,  consistent  rules  defining 
the  termination  behavior  of  processes  dependent  on  a  terminating  process. 


S.2C  Termination  Data.  The  CAIS  shall  provide  a  facility  for  termination  data  to  be  made 
available.  This  data  shall  provide  at  least  an  indication  of  success  or  failure  for  processes  that  complete 
For  processes  that  terminate  abnormally  the  termination  data  shall  indicate  abnormal  termination. 
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5.3  Communication 

5.3A  Data  Exchange.  The  CAIS  shall  provide  a  facility  for  the  excbaage  of  data  among  processes 


5.4  Synchronisation 

S.4A  Task  Waiting.  The  CAIS  shall  support  task  waiting. 

6.4B  Parallel  Execution.  The  CAtS  shall  provide  for  the  parallel  execution  of  processes. 

5.4C  Synchronisation.  The  CAIS  shall  provide  a  facility  for  the  synchronization  of  cooperating 
processes. 

S.4D  Suspension.  The  CAIS  shall  provide  a  facility  for  suspending  a  process. 

5.4E  Resumption.  The  CAIS  shall  provide  a  facility  to  resume  a  process  that  has  been  suspended. 

6.5  Monitoring 

S.SA  Identify  Reference.  The  CAIS  shall  provide  a  facility  for  a  process  to  determine  an 
unambiguous  identity  of  a  process  and  to  reference  that  process  using  that  identity. 

S.5B  RTS  Independence.  CAIS  program  execution  facilities  shall  be  designed  to  require  no 
additional  functionality  in  the  Ada  Run-Time  System  (RTS)  from  that  provided  by  Ada  semantics. 
Consequent!) .  the  implementation  of  the  Ada  RTS  shall  be  independent  of  the  CAIS. 

5.SC  Instrumentation.  The  CAIS  shall  provide  a  facility  for  a  process  to  inspect  and  modify  the 
execution  environment  of  another  process.  This  facility  is  intended  to  promote  support  for  portable 
debuggers  and  other  instrumentation  took 
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6.  INPUT/OUTPUT 


The  requirements  specified  in  this  section  pertain  to  inpnt/ontpnt  between/among  objects  (e  g  processes, 
data  entities,  communication  devices,  and  storage  devices)  unless  otherwise  stated.  All  facilities  specified 
in  the  following  requirements  are  to  be  available  to  non- privileged  processes,  unless  otherwise  specified 

The  following  definitions  pertain  specifically  to  this  section: 

DATA  UNIT  a  representation  of  a  value  of  an  Ada  discrete  type. 

DATAPATH  the  mechanism  by  which  data  units  are  transmitted  from  a  producer  to  a  consumer. 

DATASTREAM  the  data  units  flowing  from  a  producer  to  a  consumer  (without  regard  to  the 
implementing  mechanism). 

CONSUMER  an  entity  that  is  receiving  data  units  via  a  datapath. 

PRODUCER  an  entity  that  is  transmitting  data  units  via  a  datapath. 

TYPE- AHEAD  the  ability  of  a  producer  to  transmit  data  units  before  the  consumer  requests  the  data 
units 


0.1  General  Input/Output 

a.  Waiting.  The  CAIS  shall  cause  only  the  task  requesting  a  synchronous  input/output  operation 
to  await  completion. 

0.2  Virtual  I/O  Drlvtra 
0.2A  Data  Unit  Transmission 

a.  Hardcopy  terminals.  The  CAIS  shall  provide  interfaces  for  the  control  of  hardcopy  termiasls 

b.  Page  terminals.  The  CAIS  shall  provide  interfaces  for  the  control  of  page  terminals.  A  page 
terminal  transmits/receives  one  data  unit  at  a  time. 

c.  Printers.  The  CAIS  shall  provide  interfaces  for  the  control  of  character- imaging  printers  and 
bit-map  printers. 

d.  Paper  tape  drives.  The  CAIS  shall  provide  interfaces  for  the  control  of  paper  tape  drives. 


•  •  J*  »  '  •  *  »  *'**/'  **•*••»  I  »  *S*  I  ’•'*  *  s'»  .*■  s’*  »■' 
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e.  Graphics  support.  The  CA1S  shall  support  the  control  of  interactive  graphical  input /output 
devices. 

6.2B  Data  Block  Transmission 

a.  Block  terminals.  The  CAIS  shall  provide  interfaces  for  the  control  of  charac terminating  block 
terminals.  A  block  terminal  transmits/receives  a  block  of  data  units  at  a  time. 

b.  Tape  drives.  The  CAlS  shall  provide  interfaces  for  the  control  of  magnetic  tape  drives. 

6.3  Datapath  Control 

a.  Interface  level.  The  datapath  control  facilities  of  the  CAIS  shall  be  provided  at  a  level 
comparable  to  that  of  Ada  LRM  File  I/O.  That  is,  control  of  datapaths  shall  be  provided  via 
subprogram  calls  rather  than  via  the  data  units  transmitted  to  the  device. 

b.  Timeout.  The  CAIS  shall  provide  facilities  to  permit  timeout  on  input  and  output  operations. 

c.  Exclusive  access.  The  CAIS  shall  provide  facilities  to  obtain  exclusive  access  to  a 

producer/consumer;  such  exclusive  access  does  not  prevent  a  privileged  process  from 
transmitting  to  the  consumer. 

•-3A  Data  Unit  Transmission 

a.  Data  unit  site.  The  CAIS  shall  provide  input/output  facilities  for  communication  with  devices 
requiring  5-bit,  7-bit.  and  8-bit  data  units,  minimally. 

b.  Raw  input/output.  The  CAIS  shall  provide  the  ability  to  traasmit/receive  data  units  and  data 
unit  sequences  without  modification  (e  g.  transformation  of  units,  addition  of  units,  removal 
of  units). 

c.  Single  data  unit  transmission.  The  CAIS  shall  provide  facilities  for  the  input/output  of  single 
data  units.  The  completion  of  this  operation  makes  the  data  unit  available  to  it*  cousumer(s) 
without  requiring  another  input/output  event,  including  the  receipt  of  a  termination  or  escape 
sequence,  the  filling  of  a  buffer,  or  the  invocation  of  an  operation  to  force  input/output. 

d.  Datapath  buffer  site.  The  CAIS  shall  provide  facilities  for  the  specification  of  the  sites  of 
input/output  data  path  buffers  during  process  execution. 
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e.  Datapath  flashing.  The  CAIS  shall  provide  facilities  for  the  removal  of  all  buffered  data  from 
an  input/output  datapath. 

f.  Output  datapath  processing.  The  CAIS  shall  provide  facilities  to  force  the  output  of  all  data 
in  an  output  datapath. 

g.  Input/output  sequencing.  The  CAIS  shall  provide  facilities  to  ensure  the  servicing  of 
iaput/output  requests  in  the  order  of  their  invocation. 

h.  Padding.  The  CAIS  shall  specify  the  set  of  data  units  and  data  unit  sequences  (including  the 
null  set)  which  can  be  added  to  an  iaput/output  datastream.  The  CAIS  shall  provide  facilities 
permitting  a  process  to  select/query  at  execution  time  the  subset  of  data  units  and  data  unit 
sequences  which  may  be  added  (including  the  null  set). 

i.  Filtering.  The  CAIS  shall  specify  the  set  of  data  units  and  data  unit  sequences  (including  the 
null  set)  which  may  be  filtered  from  an  input  or  output  datastream.  The  CAIS  shall  provide 
facilities  permitting  a  process  to  select /query  at  execution  time  the  subset  of  data  units  and 
data  unit  sequences  which  may  be  filtered  (including  the  null  set). 

j.  Modification.  The  CAIS  shall  specify  the  set  of  modifications  that  can  occur  to  data  units  in 
an  iaput/output  datastream  (e  g.,  mapping  from  lower  case  to  upper  case).  The  CAIS  shall 
provide  facilities  permitting  a  process  to  select/query  at  execution  time  the  subset  of 
modifications  that  may  occur  (including  the  null  set). 

k.  Datastream  redirection.  The  CAIS  shall  provide  facilities  to  associate  at  execution  time  the 
producer/coosumer  of  each  iaput/output  datastream  with  a  specific  device,  data  entity,  or 
process 

l.  Input  Sampling.  The  CAIS  shall  provide  facilities  to  sample  aa  input  datapath  for  available 
data  without  having  to  wait  if  data  are  not  available. 

m.  Transmission  characteristics.  The  CAIS  shall  support  control  at  execntioa  time  of  host 
transmission  characteristics  (e.g.,  rates,  parity,  number  of  biu,  kalf/fuU  duplex). 

n.  Type-ahead.  The  CAIS  shall  provide  facilities  to  disable/easble  type-ahead.  The  CAIS  s*all 
provide  facilities  to  indicate  whether  type-ahead  is  supported  in  the  given  implementation 
The  CAIS  shall  define  the  results  of  invoking  the  facilities  to  disable/enable  type-ahead  in 
those  implementations  that  do  not  support  type-ahead  (e.g..  null-effect  or  exception  raised) 


Ir 
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o.  Echoic*  The  CAIS  (hall  provide  facilities  to  disable/eaabte  echoing  of  data  nniu  to  their 
tosrce.  The  CAIS  shall  provide  facilities  to  indkate  whether  echo-suppression  is  supported  ia 
the  given  implemeatatioa.  The  CAIS  shall  define  the  results  of  invoking  the  facilities  to 
disable/eaable  echoing  in  those  implementations  that  do  not  support  echo-suppression  (e  g., 
null  effect  or  exception  raised). 

p.  Control  input  datastream.  The  CAIS  shall  provide  facilities  to  designate  an  input  datastream 
as  a  control  input  datastream. 

q.  Control  input  trap.  The  CAIS  shall  provide  the  ability  to  abort  a  process  by  means  of 
trapping  a  specific  data  unit  or  data  unit  sequence  in  a  control  input  datastream  of  that 
process. 

r.  Trap  sequence.  The  CAIS  shall  provide  facilities  to  specify /query  the  data  unit  or  data  unit 
sequence  that  may  be  trapped.  The  CAIS  shall  provide  facilities  to  disable/eaable  this  facility 
at  execution  time. 

s.  Data  link  control.  The  CAIS  shall  support  facilities  for  the  dyoamk  control  of  data  links, 
including,  at  least,  self-test,  automatk  dialing,  hang-up,  and  broken-link  handling. 

6.3B  Data  Block  Transmission 

a.  Data  block  sue.  The  CAIS  shall  provide  facilities  for  the  specifkation  of  the  size  of  data 
blocks  during  program  execution. 

b.  Datapath  buffer  size.  The  CAIS  shall  provide  facilities  for  the  specification  of  the  sizes  of 
input/output  datapath  buffers  during  process  execution. 

c.  Datapath  flushing.  The  CAIS  shall  provide  facilities  for  the  removal  of  all  buffered  data  from 
an  input/output  datapath. 

d.  Output  datapath  processing.  The  CAIS  shall  provide  facilities  to  force  the  output  of  all  data 
in  an  output  datapath. 

e.  Input/output  sequencing.  The  CAIS  shall  provide  facilities  to  ensure  the  servicing  of 
input/output  requests  in  the  order  of  their  invocation. 

f.  Datastream  redirection.  The  CAIS  shall  provide  facilities  to  associate  at  execution  time  each 
input/output  datastream  with  a  specific  device,  data  entity  or  process 
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6.4  Data  Entity  Transfer 

».  Common  exteraai  form.  The  CAIS  shall  specify  a  represea tatioa  oa  physical  media  of  a  set  of 
related  data  entities  (referred  to  as  the  Commoa  Exteraai  Form). 


b.  Transfer.  The  CAIS  shall  provide  facilities  using  the  Commoa  Exteraai  Form  to  support  the 
traasfrr  among  CAIS  implementatioas  of  sets  of  related  data  entities  such  that  eoateats. 
attributes,  sad  relationships  are  preserved. 
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CAIS  SPECIFICATION 
COORDINATION  REPORT 


Bernard  Abrams 
Grumman  Aerospace  Corp 


INTRODUCTION 

This  report  contains  a  stannary  and  analysis  or  standards  and 
specifications  that  could  possibly  conflict  with  CAIS.  A  list  of 
applicable  standards  was  obtained  from  various  indexes  and  by 
asking  knowledgeable  people.  The  primary  index  used  was  DOD1SS 
(Department  of  Defense  index  of  Standards  and  Specifications). 
Both  government  and  industry  standards  were  examined.  Standards 
that  were  suspected  of  conflicting  or  of  being  redundant  with 
CAIS  were  read  and  are  reported  herein. 

This  report  would  not  have  been  possible  without  the 
assistance  of  the  Grumman  Aerospace  Corp.  Engineering  Standards 
Department . 
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DOCUMENT  ID:  ANSI/ANS  10.2  1982 

TITLE  Reconmend  Programming  Practices  to  Facilitate 

the  Portability  of  Scientific  Computer  Programs 

DOCUMENT  DATE  12  March  1982 

AGENCY  American  Nuclear  Society 

STATUS  Approved 

SUMMARY  Programming  practices  are  recommended  for 

making  application  programs  portable.  The  emphasis  is  on 
scientific  and  engineering  applications  in  FORTRAN.  Typical 
recomnendat ions  are  to  avoid  extensions  to  ANSI  Fortran. 

CONNECTION  TU  CAIS  There  is  no  connection.  ANSI  10.2  is 
concerned  with  achieving  portability  by  using  a  comnon  subset 
of  a  variety  of  FORTRAN  versions.  CAIS  achieves  portability  by 
standardizing  on  an  operating  system  interface  in  an 
environment  where  the  programming  language  is  standard. 


DOCUMENT  ID:  ANSI/ANS  10.5  1979 


TITLE  Guidelines  for  Considering  User  Needs 

Computer  Program  Development 


in 


DOCUMENT  DATE 

AGENCY 

STATUS 


29  August,  1979 
American  Nuclear  Society 
Approved 


SUMMARY  User  concerns  are  listed  including  proper 

application,  ease  of  use,  reliability,  and  time  required  to 
obtain  results.  Design  practices  to  achieve  programs  that  meet 
the  users  concerns  are  modularity,  automated  adjustment  to 
hardware  differences,  and  minimized  input  by  using  default 
values. 


CONNECTION  TO  CAIS  This  standard  is  a  good  summary  of  design 

practices  ror  building  user  friendly  programs,  but  it  is  not 
directly  applicable  to  CAIS  because  CAIS  does  not  define  a 
human  user  interface. 


CAIS  Specification  Coordination  Report 


DOCUMENT  ID:  ANSI  X3H1 

TITLE  OSCRL  (Operating  System  Command  &  Response 

Language)  Specification  09SD 

DOCUMENT  DATE  2  February  1984  Revision  20 

AGENCY  ANSI 

STATUS  Draft 

SU.vtvlARY  OSCRL  specifies  the  command  language  used  by  a 

human  user  to  request  operating  system  services.  The  purpose  is 
to  promote  portability  of  people  and  programs  among  general 
purpose  computer  systems.  OSCRL  has  commands  for  managing  files 
(COPY,  CREATE,  DELETE),  commands  for  managing  processes 
(SUBMIT),  and  a  procedural  language  for  controlling  commands 
(IF,  LOOP,  GO  TO,  EXIT). 

CONNECTION  TO  CAIS  There  is  a  strong  connection  between  CAIS 

and  OSCRL.  CAIS  specifies  the  language  used  by  a  computer 
program  to  call  for  operating  system  services.  These  are  the 
same  services  that  a  human  user  requests  with  OSCRL.  The  two 
languages  should  be  compatible.  If  both  specifications  are 
adopted,  then  a  user  will  use  OSCRL  to  enter  requests  which 
will  be  translated  by  a  command  interpreter  to  CAIS  calls. 

There  have  been  discussions  of  having  the  user  enter 
commands  in  Ada.  The  OSCRL  language  is  not  Ada. 

There  is  a  definite  need  to  coordinate  OSCRL  and  CAIS 
since  they  overlap  in  many  areas.  One  example  is  file  naming 
conventions.  A  detailed  comparison  of  the  OSCRL  draft  with  CAIS 
should  be  prepared. 
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DOCUMENT  ID: 
TITLE 

DOCUMENT  DATE 
AGENCY 
STATUS 
S  UNWARY 


ANSI /MIL- STD  1815A 
Ada  Programming  Language 
22  January  1983 

Ada  Joint  Programming  Office,  DoD 
Approved 

Ada  Language  Reference  Manual 


CONNECTION  TO  CAIS  In  addition  to  the  requirement  that  CAIS 

conform  to  the  "Ada  language,  MIL- STD  1815A  is  a  prototype  of 
the  format  for  CAIS.  For  example  the  precedent  of  allowing  an 
exception  to  the  outline  of  MIL-STD  962  was  set  by  MIL-STD 
181SA  and  followed  by  CAIS. 


DOCUMENT  ID: 


DoD  4120. S-M 


TITLE  Defense  Standardization  and  Specification 

Program,  Policies,  Procedures  and  Instructions 


DOCUMENT  DATE 
AGENCY 


July,  1980 


STATUS 


Mandatory  for  use  by  all  DoD  activities 


SUMMARY  The  organizational  procedure  for  making 

standards  is  described.  It  includes  organization  and 
assignments,  planning,  programming,  policies  and  procedures  for 
standardizing  documents. 


CONNECTION  TO  CAIS 
is  described  here. 


The  procedure  for  making  CAIS  a  standard 
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DOCUMENT  ID; 
TITLE 

DOCUMENT  DATE 
AGENCY 
STATUS 
SUMVIARY 


DOD-STD  7935 

Automatic  Data  System  (ADS)  Documentation 
13  September  1977 
Department  of  Defense 
Approved 


All  the  documents  that  must  be  produced  when 
developing  a  computer  system  are  describe.  Standard  outlines 
are  given. 


CONNECTION  TO  CAIS  An  implementation  of  CAIS  would  be  an  ADS,  but 
CAI S  i  tsei  f  is  not.  It  might  be  considered  an  FD  (Functional 
Description)  which  is  one  of  the  documents  of  the  development 
life  cycle  required  by  DOD-STD  793S. 


DOCUMENT  ID:  FIPS  PUB  30 


TITLE  Software  Summary  for  Describing  Computer 

Programs  and  Automated  Data  Systems 


DOCUMENT  DATE 


30  June  1974 


AGENCY 


Institute  for  Computer  Science,  NBS 


STATUS 


Approved 


SUMviARY  This  publication  provides  a  standard  software 

sumnary  form  (SF-185)  for  describing  computer  programs  and 
automated  data  systems  for  identification,  reference,  and 
dissemination  purposes. 


CONNECTION  TO  CAIS  none 
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DOCUMENT  ID: 


FIPS  PUB  41 


TITLE  Computer  Security  Guidelines  for  Implementing 

the  Privacy  Act  of  1974 


DOCUMENT  DATE 
AGENCY 


STATUS 


30  May,  1975 

National  Bureau  of  Standards 
Approved 


SUMvlARY  This  is  general  guidelines  for  computer 

security  including  physical  security,  entry  controls,  data 
encryption,  and  programing  practices. 

CONNECTION  TO  CAIS  Nothing  in  CAIS  prevents  the  implementat i on  of 
the  security  provisions  of  FIPS  PUB  41. 
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DOCUMENT  ID: 


FIPS  PUB  46 


TITLE 

DOCUMENT  DATE 
AGENCY 


Data  Encryption  Standard 
IS  January  197? 

Institute  for  Computer  Science,  NBS 


STATUS  Approved 

SUM.1ARY  An  algorithm  is  described  for  enciphering  and 

decipher i ng  a  block  of  data.  The  algorithm  is  applied  to  data 
when  it  leaves  a  system,  and  again  when  it  reenters  the  system. 
The  implementation  method  is  not  described.  Whether  or  not  the 
encryption  is  done  in  the  CPU  or  in  separate  modules  is  not 
speci f i ed. 


CONNECTION  TO  CAIS  Encryption  translates  a  given  bit  pattern  into 
a  random  pattern.  Therefore  the  transmission  system  after  the 
point  of  encryption  must  pass  all  bit  combinations.  Any  CAIS 
feature  that  prevents  the  transmission  of  specific  characters 
could  interfere  with  encryption. 


DOCUMENT  ID;  IEEE  162-63 

TITLE  Standard  Definition  of  Terms  for  Electronic 

Digital  Computers 

DOCUMENT  DATE  Dec  63 

AGENCY  IEEE 

STATUS  Approved 

SUMMARY  This  is  a  hardware  oriented  glossary. 

CONNECTION  TO  CAIS  Possible  use  in  definitions. 
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DOCUMENT  ID;  IEEE  STD  730-81 


TITLE  Standard  for  Software  Quality  Assurance  Plans 

DOCUMENT  DATE  1981 


AGENCY  IEEE 

STATUS  Approved 

SUMMARY  This  standard  describes  what  a  SqAP  (Software 

Requirements  Assurance  Plan)  should  be.  A  SQAP  applies  to  a 
software  development  project.  The  activities  and  documents 
needed  for  QA  are  listed.  The  minimum  activities  are  SRR 

(Software  Requirements  Review),  PDR  (Preliminary  Design 
Review),  CDR  (Critical  Design  Review),  SVR  (Software 
Verification  Review),  Functional  Audit,  Physical  Audit,  and  In 
Process  Audit.  The  minimum  documents  are  SRS  (Software 
Requirements  Specification),  SDD  (Software  Data  Design)  SVP 
(Software  Verification  Plan)  and  SVR  (Software  Verification 
Report ) . 


CONNECTION  TO  CAIS  The  CAIS  itself  is  an  interface  standard,  not 
executable  software,  and  therefore  is  not  subject  to  the  same 
QA  requirements  as  a  software  product.  However,  CAIS  is  a 
product  and  as  such  should  have  some  QA  plan.  A  CAIS 
implementation  is  software  and  needs  a  full  QA  plan. 


DOCUMENT  IDs 


MIL  S  52779A 


TITLE 

Requi rements 
DOCUMENT  DATE 
AGENCY 
STATUS 


Software  Qua 

1  August,  1979 
US  Army  Computer 
Approved  by  Depa 


ity  Assurance 

Systems  Command 
tment  of  Defense 


Program 


SUMMARY  This  standard  is  applicable  to  computer 

programs  and  related  data  and  documentation.  A  Software  Quality 
Assurance  Program  is  described.  Included  is  the  requirement  for 
practices  and  procedures  to  assure  compliance.  In  addition  the 
tools,  techniques,  and  methodologies 


CONNECTION  TO  CAIS  An  implementation  of  CAIS  will  require  a 

QA  program. 


CAIS  Specification  Coordination  Report 


DOCUMENT  IL);  MIL- STD  12D 

TITLE  Abbreviations  for  Use  on  Drawings,  and  in 

Specifications,  Standards,  and  Technical  Drawings. 

DOCUMENT  DATE  29  May  1981 

AGENCY  Department  of  Defense 

STATUS  Approved 

SUMV1ARY  This  standard  contains  a  list  of  approved 

abbreviations  for  use  in  specifications  and  standards.  The  list 
is  by  the  full  spelling  and  is  cross  referenced  by 
abbreviation.  An  interesting  quote  is  "when  in  doubt,  spell  it 
out". 


CONNECTION  TO  CAIS  Abbreviations  in  CAIS  should 


contradict  MIL-S 


An  abbreviation  such  as  "CAIS”  that 


not 
i  s 


too  specific  to  appear  in  M1L-STD  12D  is  acceptable. 


The  approved  abbreviation  for  Identification  is  IDENT.  The 
use  of  ID  in  the  CAIS  text  violates  MIL- STD  12D.  A  non¬ 
standard  abbreviation  may  be  used  in  a  computer  name.  Agreement 
between  computer  names  and  MIL- STD  12D  is  optional.  The 
standard  is  concerned  with  abbreviations  in  text. 


CAIS  Specification  Coordination  Report 


DOCUMENT  ID? 


MIL  STD  961, 


TITLE 


Military  Specification,  Preparation  Of 


DOCUMENT  DATE 


22  September  1981 


AGENCY 


STATUS 


Approved 


SUMMARY  The  format  of  a  MIL  Specification  is 

described.  The  use  if  "will"  and  "shall”,  the  standard  section 
numbering,  style  and  word  usage  are  specified. 


CONNECTION  TO  CAIS  CAIS  is  a  standard,  not  a  specification. 

A  companion  document,  MIL  STD  962  applies  to  CAIS. 


DOCUMENT  ID: 


MIL  STD  962 


TITLE  Outline  of  Forms  and  Instructions  for  the 

Preparation  of  Military  Standards 


DOCUMENT  DATE 


22  September,  1975 


AGENCY 


DoD,  Defense  Electronics  Supply  Center 


STATUS 


Approved 


SlMvlARY  This  standard  gives  the  format  of  a  MIL 

Standard  including  word  usage,  paragraph  identification, 
symbols,  format  for  tables,  use  of  footnotes,  and  figure  sizes. 
A  standardized  outline  is  described. 


CONNECTION  TO  CAIS  MIL  STD  962  is  applicable  to  CAIS.  CAIS 
does  conform  in  terms  of  format  and  style.  However  CAIS  does 
not  follow  the  standard  outline.  This  exception  is  necessary 
because  the  standard  outline  does  not  fit  an  interface 
definition  like  CAIS. 


3-284 


A-1*  Ju?**a_^ 


CAIS  Specification  Coordination  Report 


DOCUMENT  ID: 


TITLE 

DOCUMENT  DATE 


AGENCY 

STATUS 


MIL-STD  1644 


Trainer  System  Software  Development 
7  March  1979 

Navel  Trainer  Equipment  Center 
Approved 


SUMMARY  This  is  one  of  several  standards  on  the 

procedure  for  developing  software.  The  others  are  MIL  STD  1679 
and  MIL  STD  SDS.  The  documents  required  and  the  procedures  to 
be  followed  are  specified. 


CONNECTION  TO  CAIS 


None  since  CAIS  is  not  training  equipment 


DOCUMENT  ID: 
TITLE 

DOCUMENT  DATE 

AGENCY 

STATUS 


MIL-STD  1679 

Weapon  System  Software  Development 
1  December  1978 
NAVMAT  09Y 
Approved 


SUMvlARY  This  standard  controls  the  way  software  is 

developed  with  emphasis  on  documents  and  procedures. 

CONNECTION  TO  CAIS  Weapon  System  software  is  defined  broadly 

enough  to  include  software  development  facilities  of  which  CAIS 
is  a  part.  An  implementation  of  CAIS  should  follow  one  of  the 
software  development  standards. 
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CAIS  Specification  Coordination  Report 


DOCUMENT  ID:  MIL- STD  SDS 

TITLE  Defense  System  Software  Development 


DOCUMENT  DATE  20  December  1983 

AGENCY  USAF  KADC 


STATUS  Draft  Not  Approved 

SUMMARY  The  methods  and  documents  for  software 

development  are  specified.  Structured  programming  constructs 
are  required.  This  standard  is  a  replacement  for  MIL-STD  1679 
and  MIL-STD  1644. 


Important  quotes  are  "the  contractor  is  encouraged  to 
incorporate  conmercial  ly  available  software”  and  "the 
contractor  shall  produce  code  that  can  be  regenerated  and 
maintained  using  only  government-owned  or  contractually 
deliverable  software." 


CONNECTION  TO  CAIS  There  is  no  conflict.  This  Standard 
controls  the  way  CAIS  is  implemented. 


CONCLUSION 

The  only  standard  found  to  have  potential  overlap  is  OSCiiL. 
There  are  other  standards  that  specify  the  way  a  standards 
document  is  formatted  or  the  quality  control  of  a  program.  These 
must  be  considered  in  making  CAIS  a  standard,  but- have  no  direct 
conflict . 


CAIS  Specification  Coordination  Report 


INDEX 
ANSI  X3HI 
ANSI /ANS  10.2  82 
ANSI /ANS  10. 5  1979 
ANSI /MIL-STD  181 SA 
Do D  4120. 3-M 
DOD-STD  7935 
FIPS  PUB  30 
FIPS  PUB  41 
FIPS  PUB  46 
IEEE  162-63 
IEEE  STD  730-81 
MIL  S  S 2 7 7 9 A 
MIL  STD  96 1A 
MIL  STD  962 
MIL-STD  12D 
MIL-STD  1644 
MIL-STD  1679 
MIL-STD  483 
MIL-STD  SDS 


OSC&L 

Programming  Practices  for  Portability 
Guidelines  for  Considering  User  Needs 
Ada  Programming  Language 
Defense  Standardization  Procedures 
Automatic  Data  System  (ADS)  Documentation 
Summary  for  Describing  Computer  Programs 
Computer  Security  Guidelines  for  Privacy 
Data  Encryption  Standard 
Standard  Definition  of  Terms  for  Computers 
Software  Quality  Assurance  Plans 
Software  Quality  Assurance  Program 
Military  Specification,  Preparation  Of 
Outline  of  Forms  for  MIL  Standards 
Abbreviations 

Trainer  System  Software  Development 
Weapon  System  Software  Development 
Configuration  Management  Practices 
Defense  System  Software  Development 
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KIT  I A  DRAFT  PROPOSAL 


The  KITIA  believe*  thet  positive  ection  should  be  taken  to  eddress  the  perceived  risks  incurred 
by  the  current  opprooch  to  achieving  e  common  APSE  interface  set.  In  January  of  1 985,  end 
RFP  esking  for  e  design  of  CAIS  2.0  is  expected  to  be  issued.  This  project  will  provide  e  CAIS 
design  derived  from  end  competible  with  the  current  version. 


The  current  version  of  the  CAIS  (1.3)  hes  been  criticized  es  too  smbitious.  This  is,  in  eprt, 
beceuse  it  prescribes  s  model  of  en  opereting  system  which  is  besedon  en  entity- relationship 
database  ( the  'node  model* ).  Beceuse  current  opereting  systems  do  not  have  this  structure, 
concerns  have  been  expressed  about  the  risks  in  its  schedule,  its  cost,  and  its  technics)  viability. 
In  addition,  the  current  CAIS  hes  mode  no  explicit  provision  for  implementations  on'  end  beside' 
existing  dote  management  end  operating  systems.  To  insure  uninterrupted  progress  in  the  Ade 
program  end  to  provide  transition  paths  fbr  current  compilers  and  environment  efforts,  the 
KITIe  recommends  thet  AJPO  initiate  e  second,  parallel  effort. 


We  recommend  thet  s  second  RPF  be  issued  simultaneously  with  that  fbr  CAIS  2.0.  This  second 
RFP  should  contract  a  project  to  explore  alternative  CAIS  designs  to  reduce  risk,  end  enhance  the 
Ada  community's  ability  to  rapidly  deploy  Ada  tools  into  existing  software  development 
environments.  This  RFP  should  request  an  alternative  CAIS  design  end  working  prototype  which 
addresses  the  following  objectives: 


1.  The  interfaces  shall  be  capable  of  being  implemented  in  at  least  two  existing 
environments  without  modification  to  their  host  operating  systems  (kernel) 

2.  There  shell  be  minimal  data  management  coding  needed  in  th  implementation  of  the 
interfaces  to  supplement  the  underlying  facilities.  This  shell  maximize  use  of 
existing  structures  end  resources. 

3.  Ada  tools  using  the  interfaces  shall  be  capable  of  operating  on  existing  objects  end 
devices,  end  cooperate  with  existing  tools. 

4.  Pre-existing  tools  shall  be  capable  of  opereting  on  data  objects  created  by  the  Ade 
tools  using  the  new  Interfaces. 

5.  Ada  tools  which  use  the  interfaces  shall  be  capable  of  being  Invoked  end  controlled 
by  pre-existing  tools  end  command  languages. 

6.  The  interfaces  shall  be  specified  by  e  set  of  Ade  package  specifications. 


■.v.vV'O.v.v: 


ADA  PAPER  H 

by  3 

Dr.  Chris  Napius  *»| 

The  following  paper  is  presented  for  your  information  and  consideration 
by  Dr.  Chris  Napjus.  Dr.  Nap jus  is  a  respected  member  of  the  Software 
Engineering  Community  and  is  currently  employed  by  the  DoD.  Dr.  Napjus 
has  followed  Ada  from  its  inception  and  is  one  of  its  strongest  propon- 
nents . 

PREAMBLE/PARABLE 

Charles  Coren  revolutionized  the  world  of  bridge  forty  years  ago 
with  his  new  point-count  system  of  bidding.  Today,  all  American  bridge 
players  know  and  understand  Coren.  or  "Standard  American”  as  it  is  now 
called.  Yet  very,  very  few  use  the  system  in  unmodified  form,  and  the 
variations  used,  encompassing  various  combinations  of  features,  are 
enormous.  Yet  most  people  use  "straight  Coren”  features  for  a  large  plu¬ 
rality  of  their  bids,  as  the  variations  apply  to  specific,  often  fairly 
rare,  situations.  Moreover,  all  can  "fall  back  on  Standard  American" 
whenever  they  are  playing  with  a  new  partner,  gradually  deviating  from 
it  over  a  period  of  time  as  they  agree  to  variations  which  are  to  their 
mutual  liking. 

The  fact  that  "Goren”  still  forms  the  basis  for  most  of  the  bid¬ 
ding  systems  used  today,  despite  forty  years  of  evolution  and  the  at¬ 
tempted  introduction  of  a  great  many  different  "complete"  systems,  is  a 
testament  not  only  to  the  quality  of  the  system,  but  also  a  reminder 
that  a  total  revision  of  the  way  things  are  done  constitutes  an  enormous 
undertaking.  There  are  probably  few  -  perhaps  no  -  bridge  players  who 
believe  that  Standard  American  (or  their  particular  variant  of  it)  is 
the  best  possible  system.  What  they  agree  to  is  that  it  is  a  good  one; 
that  it  is  understood  by  anyone  with  whom  they  might  wish  to  play:  that 
it  is  adaptable  to  whatever  particular  style  they  may  like;  that 
developing  an  entire,  consistent  system  of  their  own  is  essentially  im¬ 
possible;  and  that  even  learning  a  new  system,  developed  by  someone 
else,  would  cost  more  in  time  and  effort  than  any  benefit  which  might 
ultimately  accrue. 

The  analogy  between  bidding  systems  and  the  Ada  environment 
should  be  obvious,  and  should  be  heeded.  It  is  always  possible  to 
develop  a  better  system  than  one  you  have,  but  the  effort  involved  may 
well  not  be  worth  it.  There  is  no  single  "best”  answer,  and  one  will 
never  be  able  to  design  a  system  that  any  sizeable  percentage  of  comput¬ 
er  scientists  would  agree  was  the  best  attainable  at  that  time.  What  is 
important  is  to  have  a  good,  useful  system;  better  than  what  one  has 
currently;  which  can  be  learned  fairly  readily  so  that  it  will  be  under¬ 
stood  and  capable  of  being  used  by  any  Ada  developer.  Like  bridge 
players,  software  developers  will  find  it  far  more  useful  to  have  a  sys¬ 
tem  which  is  solid  and  consistent,  but  easily  modifiable  in  particulars  1 

to  suit  a  given  environment.  !] 


SOME  RELEVANT  CONSIDERATIONS 

1.  Ada  was  conceptualized,  designed,  funded,  and  developed  to  solve  a 
pressing  DoD  need.  The  fact  that  it  is  more  widely  useful  than  ini¬ 
tially  envisioned  is  not  a  reason  for  deviating  from  its  intended 
focus.  The  degree  to  which  it  will  benefit  non-DoD  users  is  largely 
synergistic.  Its  benefit  to  DoD  is  essential. 


2. 


As  a  percentage  of  the  entire  field  of  users,  few  (particularly 
within  DoD)  have  any  meaningful  tools  at  all,  let  alone  integrated 
environments.  What  is  essential,  as  a  first  step,  is  to  change  this 
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situation,  even  if  the  result  is  not  "state-of-the-art"  for  any  par¬ 
ticular  state-of-the-art.  There  is  vastly  more  to  be  gained  by  moving 
the  bulk  of  the  users  SOON  from  15  years  behind  the  S-O-T-A  to  only  5 
years  behind  than  there  is  by  providing  the  relatively  few  who  are 
working  at  the  S-O-T-A  with  a  much  more  advanced  environment  SOMETIME 
in  the  future.  In  short,  we  should  not  be  applying  our  effort  to  de¬ 
fining  an  environment  for  the  90* s  when  the  bulk  of  the  users  are 
still  working  in  the  70's. 

3.  There  is  also  a  significant  danger  to  the  entire  Ada  effort  by  wait¬ 
ing  too  long  to  provide  something  practical.  Aside  from  the  obvious 
material  loss  in  having  to  maintain  too  many  non-standard  systems 
that  much  longer,  Ada  will  not  be  used  extensively  until  it  is  able 
to  promise  a  SUBSTANTIAL  benefit  over  other  systems.  This  requires  a 
usable  environment.  The  longer  we  wait,  the  longer  it  will  be  until  a 
large  number  of  people  are  trained  on  Ada  and,  as  the  widely  pro¬ 
claimed  benefits  recede  ever-farther  into  the  twilight,  the  emphasis 
on  training  people  will  become  less  and  less.  The  community  is  ready 
for  Ada  NOW.  The  number  of  non-believers  will  grow  exponentially  the 
longer  it  continues  to  be  Something  for  the  future." 

4.  Even  a  relatively  small  set  of  manually- invoked  tools  would  be  a  sig¬ 
nificant  improvement  over  the  common  situation  today.  Moreover,  in¬ 
crements  11  ty  does  not  preclude  improvement.  We  can  have  it  both  ways 
if  we  do  it  right.  Perhaps  most  inportant,  the  average  user  is  not 
ready  to  utilize  some  beautiful  state-of-the-art  system.  He  needs  ex¬ 
perience  with  tools  in  general  before  he  will,  or  can,  make  use  of  an 
automated  system  which  he  doesn't  understand.  There  is  much  to  be 
said  for  crawling  before  milking. 

5.  It  would  certainly  be  nice  to  have  an  Ada  environment  which  is  as 
methodology-  Independent  as  posssible.  But: 

a.  this  is  an  argument  for  keeping  the  number  of  MAPSE  tools 
small 

b.  the  need  for  methodology  independence  is  far  greater  when 
looking  at  the  total  class  of  potential  users  vice  the  DoD  class 

c.  ANY  consistent  methodology,  suboptima 1  as  it  might  (and  sure¬ 
ly  will)  be,  is  better  than  NONE  (the  usual  situation  now) ,  and 
may  Indeed  be  better  than  a  combination  of  (presumably)  optim¬ 
ized  methodologies  within  too  small  an  organization. 

6.  It  is  useful  to  think  of  software  environment  technology  as  being  in 
four  tiers: 

a.  research  technology  (most  appropriate  to  academia) 

b.  prototype  usage  (Industrial  research/technology  groups) 

c.  well  understood,  conaaon  technology  (some  usage,  especially 
larger  firms) 

d.  outmoded/outdated  methods  (the  bulk  of  the  community,  espe¬ 
cially  DoD) 

7.  With  respect  to  these  tiers,  DoD  (and  much  of  Industry)  has  its  ef¬ 
forts  in  3  and  4,  predominately  4.  The  crying  need  is  to  move  all  4- 
level  projects  to  3  as  soon  as  possible,  and  the  KIT  should  be  devot- 


ing  aost  of  ita  attantion  to  this  goal.  Laval-3  tochnology,  undei — 
stood,  eaally-teachable,  not-too-draatlc  a  departure  la  what  projact 
managers  naad  NOW.  Such  a  move  from  tha  tochnology  of  tho  60 * a  and 
70 'a  to  that  of  tha  80* a  la  oonslstant  with* 

a.  naad 

b.  maxima  cost  savings 

c.  tha  Lnpetus  bahlnd  Ada 

d.  Congr ass Iona 1  guidance 

a.  provision  of  a  vehicle  for  subsequent  Improvements. 

8.  I  think  that  the  KIT  is  likely  a  victim  of  its  own  constitution  of 
very  intelligent,  highly  competent  computer  scientists.  It  is  all  too 
normal  to  have  little  Interest  in  that  which  you  consider  mundane;  to 
have  too  little  concern  with  that  part  of  the  world  you  don't  see;  to 
try  to  design  the  best  system  of  which  you  are  capable  (which  may  not 
be  the  most  cost-effective) ;  and  to  concentrate  on  aspects  that  are 
of  personal  interest  to  you  (and,  not  incidentally,  of  sufficient 
research  interest  to  permit  publication) .  I  think  that  this  may  ex¬ 
plain  much  of  the  KIT's  lack  of  tangible  achievement  to  date.  There 
is  too  much  commonality  of  interests  and  background,  which  almost 
guarantees  that  many  problems  will  be  viewed  within  a  limited  con¬ 
text.  In  fact,  the  KIT  would  benefit  from  infusion  of  others  with 
very  diverse  backgrounds.  What  is  needed  is  a  broad  range  of  back¬ 
grounds,  interests,  and  goals  ranging  from  the  very  blue  sky  to  the 
ln-the-trenches  users,  and  everything  in  between. 

9.  The  KIT,  and  the  Ada  community,  cannot  afford  to  wait  for  fruition  of 
a  "best  possible  solution,"  which  may  require  "only  a  few  more  months 
(or  years)"  of  study  in  order  to  become  feasible  on  a  wide  scale. 


MY  OWN  (DISJOINTED)  VIEW  OF  WHAT  THE  MAPSE/STANDARD  TOOL  SET  SHOULD  BE 

1.  It  must  be  limited,  modifiable,  substitutable,  and  expandable.  But 
modifications  must  be  carefully  controlled,  determined  to  be  for  very 
solid  reasons,  and  centrally  disseminated.  I  believe  that  we  need 
tool  validation  for  MAPSE  tools  to  ensure  that  they  do  AT  LEAST 
everything  which  it  has  been  decided  MJST  be  available  in  the  stan¬ 
dard  MAPSE. 

2.  Like  Ada  itself,  the  tools  must  be  oriented  toward  ease  of  use,  re¬ 
gardless  of  any  added  burden  this  may  impose  on  the  developers  of  the 
tools. 

3.  I  agree  that  the  existing  STONEMAN  is  inadequate,  but  believe  we  need 
an  expanded,  updated,  consolidated  revision  (a  la  STRAMMAN,  WOODEN- 
MAN.  TINMAN,  STEELMAN)  rather  than  a  new,  replacement  document. 

4.  The  basic  MAPSE  must  provide  a  standard  set  of  tools,  with  a  standard 
MINIMAL  set  of  functions  which  they  perform,  and  a  standard,  common 
command  language  which  can  invoke  them.  Supersets  are  fine  (of  tools, 
of  command  language,  or  of  functions  performed  by  a  specific  tool)  SO 
LONG  AS  the  basic,  reulred  tools,  functions,  and  commands  are  there, 
and  the  user  can  be  assured  that  a  given  contend  will  result  in  a 
given,  known  set  of  transformations.  A  given  environment  may  have  ad- 
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ditlonal  tools,  tools  which  do  more  than  thslr  minimum  required  func¬ 
tions,  and  altomativs  ways  of  Invoking  thorn  (to  include,  perhaps, 
self-invoking  mechanisms  from  one  tool  to  the  next.)  But  the  basic, 
STMOARD  nechanisas  must  be  there. 

5.  Like  a  basic  bridge  bidding  systea,  with  additional  conventions,  my 
view  of  the  MAPSE  is  one  of  a  relatively  modest  set  of  relatively 
simple  tools,  ALWAYS  available  in  ANY  Ada  environment,  which  will  be 
learned  by  and  under  stood  by  ALL  Ada  developers.  Organizations  or 
Individuals  can  add  their  own  favorite  modifications  to  this  base, 
but  can  count  on  the  basic  set  at  all  times,  and  can  always  revert  to 
it  if  desired.  Such  a  scheme  should  not  only  maximize  transportabil¬ 
ity  of  programmers,  but  also  accommodate  itself  well  to  various  skill 
levels  within  a  project  or  organization.  Newer,  less  experienced  per¬ 
sonnel  can  become  productive  rapidly  by  using  the  more  basic  (and 
known)  mechanisms,  only  gradually  extending  their  utilization  to  more 
exotic  features.  Older  hands  can,  simultaneously,  make  use  of  whatev¬ 
er  features  their  particular  (tailored)  environment  may  offer. 
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